Hello again,
Here is finally what I have done to solve that problem.
First of all, I have to say that I generally don't use Costello for my =
test
cases, because I can now write most of the XML scripts by hand.
So I have taken my previous scripts which do not work any more with
assertImage() on jpeg captures.
I have created a bsh function as follows:
<expression>
capture(ref, filename)
{
robot =3D new abbot.tester.Robot();
comp =3D component(ref);
image =3D robot.capture(comp, true);
currentdir =3D script.getDirectory();
file =3D new java.io.File(currentdir, filename);
output =3D new java.io.BufferedOutputStream(
new java.io.FileOutputStream(file));
encoder =3D new com.keypoint.PngEncoder(image,
com.keypoint.PngEncoder.NO_ALPHA, 0, 1);
output.write(encoder.pngEncode());
output.flush();
output.close();
}
</expression>
This method does the capture of the component with reference "ref", =
under
the file with name "filename" on the current script directory. The file =
is
encoded in PNG mode.
For PNG encoding, I have found the following OSS library (LGPL)
http://catcode.com/pngencoder/
which is very simple to use (only 2 classes, and in fact the function =
above
needs only one!)
Now I have added the following line before each assertImage lines in my
script:
<expression>
capture("drawing-area", =
"script-01-check-boards-1.xml-drawing-area-2.jpg");
</expression>
Please note that I did not change my original file names (jpg extension)
although they will really be png files and not jpeg, but that does not =
make
any harm. I was simply too lazy to change the file extensions in my =
scripts
;-)
This way, the only thing I got to do was launching each of my scripts =
once
with Costello (I also had to add the new pngencoder.jar to the Costello
classpath on launch): this would create/override all capture files as =
png
captures. Then final step was to remove (or comment out) all calls to =
the
capture() method in my scripts, and finally run them from Junit (to =
check
that they worked well).
That's it!
An interesting side effect of this is that if I change anything later in =
my
tests that would need to redo a capture, then I just have to reactivate =
the
capture() method calls once and that's it! Very convenient (at least =
more
convenient than proceeding again with Costello to recapture the =
components
during the script execution)!=20
So finally I did not have to modify anything in abbot source code itself =
(I
wanted to avoid it because I like to use libraries "out of the box").
However, I think it would not be difficult to enhance the capture method =
in
Costello to use the PNG encoding library (or class actually) that I
mentioned above (note that its author claims it works with JDK1.2 and =
above,
but I only checked it on 1.4).
Cheers
Jean-Francois
-----Original Message-----
From: abbot-users-bounces@...
[mailto:abbot-users-bounces@...] On Behalf Of Timothy =
Wall
Sent: Tuesday, December 12, 2006 11:27 PM
To: Jean-Francois Poilpret
Cc: 'Abbot Users'
Subject: Re: [abbot-users] [abbot - Help] RE: Cannot get AssertImage to =
work
Many thanks for that insight, J-F. I agree, a png storage would be =20
preferable. Patches welcome (maybe using ImageIO, maybe not; I =20
generally try to keep 1.3 source compatibility).
T.
On Dec 12, 2006, at 9:55 AM, Jean-Francois Poilpret wrote:
> Hello,
>
> That's funny, I have just bumped into the same problem a few days ago.
>
> Strangely, I had changed the way my graphics application used =20
> rasters for
> image temporary storage (to simplify I switched from int[] rgba to =20
> byte[]
> r,g,b), and after that my test cases did not work anymore.
> At that time, I suspected I did have to recapture all images again =20
> (with
> Costello) and everything would go fine.
> However, after doing that it still did not work!
> NB: capture and tests run are on the same environment (same machine).
>
> After scratching the problem a little bit (and taking a look at =20
> what abbot
> does for image comparison), I think I have the beginning of a lead: =20
> images
> captured by costello are stored under jpeg format; even though with =20
> quality
> 1.0f, I doubt this compression would be lossless (AFAIR jpeg =20
> compression is
> always lossful).
> However during comparison of the actual component image and the stored
> (jpeg) image, abbot does the following (simplified a bit):
> - read the jpeg file and create (jpeg decompression) a =20
> BufferedImage from it
> - compare with the original component BufferedImage (bit per bit)
> What is the probability of the jpeg-uncompressed image being the =20
> same as the
> runtime image, 100%? I am afraid not, it may be 98%, 99%, I don't =20
> know.
> Maybe there are also other factors that could possibly make jpeg =20
> compression
> lossless in some cases (but I don't know these factors...) but not =20
> all.
>
> That would explain that your file comparison works, because if you
> jpeg-compress the same image twice with the same setting (quality =20
> 1.0f),
> then you would obtain the same File (NB: on the same platform).
>
> I wonder if the abbot way to compare images should not be fixed in =20
> one of
> the following ways:
>
> 1- use png (lossless) instead of jpeg for image capture (and =20
> comparison).
> Problem could be lack of support for png compression in jdk.
>
> 2- go on with jpeg, but change the comparison this way:
> - compress the component image to jpeg (quality 1.0f)
> - compare the resulting byte[] with the byte[] content of the jpeg
> capture (I did not investigate any platform incompatibility problems)
>
> What do you think?
>
> For the moment, I think I will work around the problem by =20
> implementing way 2
> (I'll write a bsh function to do that for me, and use it in my test =20
> scripts
> instead of assertImage).
>
> Cheers
>
> Jean-Francois
>
> -----Original Message-----
> From: abbot-users-bounces@...
> [mailto:abbot-users-bounces@...] On Behalf Of =20
> Timothy Wall
> Sent: Thursday, December 07, 2006 2:25 AM
> To: Abbot Users
> Cc: boomtown15@...
> Subject: Re: [abbot-users] [abbot - Help] RE: Cannot get =20
> AssertImage to work
>
> The image comparison was originally done by doing exactly what you
> suggest. Both images were written to file and compared.
>
> Turns out that the files are not cross-platform (at least I think
> that's the case); might be a byte-ordering issue or different default
> quality settings, I'm not sure. Tests would work on w32 but fail on
> OSX and linux.
>
> Comparing files also ends up testing some stuff that is actually
> unrelated to the image itself (file format settings), but if it works
> for you, great.
>
>
> On Dec 6, 2006, at 1:54 PM, SourceForge.net wrote:
>
>>
>> Read and respond to this message at:
>> https://sourceforge.net/forum/message.php?msg_id=3D4047281
>> By: boomtown15
>>
>> In case anyone has run into this problem I found a workaround.
>> Instead of comparing
>> the images I write out both images to file (the first one is
>> already written
>> on recording) and compare the two binary files. This does seem to
>> work correctly.
>> If anyone is interested in the code let me know. I've also changed
>> the format
>> of the files from jpg to png. Png's are usually much smaller.
>>
>> _____________________________________________________________________ =
>> _
>> You are receiving this email because you elected to monitor this
>> forum.
>> To stop monitoring this forum, login to SourceForge.net and visit:
>> https://sourceforge.net/forum/unmonitor.php?forum_id=3D168262
>
> Timothy Wall
> http://abbot.sf.net
>
>
>
> ---------------------------------------------------------------------- =
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =20
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?=20
> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
> _______________________________________________
> abbot-users mailing list
> abbot-users@...
> https://lists.sourceforge.net/lists/listinfo/abbot-users
>
>
> =09
>
> =09
> =09
> ______________________________________________________________________ =
> _____
> Yahoo! Mail r=E9invente le mail ! D=E9couvrez le nouveau Yahoo! Mail =
et =20
> son interface r=E9volutionnaire.
> http://fr.mail.yahoo.com
>
>
> ---------------------------------------------------------------------- =
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =20
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?=20
> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
> _______________________________________________
> abbot-users mailing list
> abbot-users@...
> https://lists.sourceforge.net/lists/listinfo/abbot-users
Timothy Wall
http://abbot.sf.net
-------------------------------------------------------------------------=
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share =
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
_______________________________________________
abbot-users mailing list
abbot-users@...
https://lists.sourceforge.net/lists/listinfo/abbot-users
___________________________________________________________________________
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses
http://fr.answers.yahoo.com
|