Le 27/02/2014 19:28, Damjan Jovanovic a écrit : > The raw image has the XP TITLE field in IFD0, but the test writes it > into the EXIF IFD and then reads it from any IFD, so it could find it > the wrong one. The search order must be different, but I don't > understand why.
I think I have understood why I get different results on the two computers. The first line of the test is a call to getImageWithExifData(), which seem to basically loop over all files from a list until it finds one accepted by which HAS_EXIF_IMAGE_FILTER. The files list is created by static code run at ImagingTest class loading. The problem is that several files could be accepted, and only the first one is retrieved, and also that file traversal order is not deterministic here, as at each directory level it does a loop on the return value of the listFiles() method. The order of the files returned is not deterministic. I think on Linux it depends on the inode numbers, so it depends on how the folders tree has been created. If the files are not changed, this order remains constant and that explains why one of my computers always fail and the other always succeeds. The computer for which the test succeeds uses src/test/data/images/jpg/1/Canon Powershot SD750 - 2007.12.26.n.IMG_3704.JPG for this test. The computer for which the test fails uses src/test/data/images/jpg/2/2008-07-27+-+Photo+216+-+WE+a+l'etang+de+Blodelsheim.jpg for this test. There are also other files that do pass the filter. If I force the files loop to use lexicographic order, the test is run src/test/data/images/iptc/1/Oregon Scientific DS6639 - DSC_0307 - iptc added with irfanview.jpg (and succeeds). If I force the files loop to use reverse lexicographic order, the test is run with src/test/data/images/jpg/3/img_F028c_small.jpg (and succeeds too). So the first thing I would say is that the test suite is not deterministic, in that it can perform some tests on different files depending on the computer. One way to force a specific order would be to add for example a call like Arrays.sort(files) after the call to file.listFiles() near line 67 of FileSystemTraversal.java in test.util. Note that this uses File.compareTo which is lexicographic comparison. This may give different results on Windows and Linux for example if files with same names but different case would be used as case is not significant for file names on Windows. However, there are no files with names differeing only on case, so it should be OK here. Now considering that I was (un)lucky enough to have my system select src/test/data/images/jpg/2/2008-07-27+-+Photo+216+-+WE+a+l'etang+de+Blodelsheim.jpg file for the test, here is a small analysis I have done on this. You can probably get the same results by forcing this file to be selected, for example simply by copying it directly on src/test/data/images image root folder. Here is what I see by single stepping using a debugger. I don't know anything about image formats, so please forgive any misunderstandings below. The initial image seems to have four directories (instances of TiffOutputDirectory) with the following types: DIRECTORY_TYPE_ROOT, DIRECTORY_TYPE_EXIF, DIRECTORY_TYPE_INTEROPERABILITY, and DIRECTORY_TYPE_SUB. When the image is read, the root directory contains an entry (instance of TiffOutputField) with tag 0x9c9b, XPTITLE and value "WE à l'étang de Blodelsheim". During the test, the EXIF directory is retrieved and four fieldx XPAUTHOR, XPCOMMENT, XPSUBJECT and XPTITLE are inserted into it. So after this insertion, two different directories both contain a different TiffOutputField with tag XPTITLE, one with the initial value "WE à l'étang de Blodelsheim" and the second one with a dummy value "title". The rewriter.updateExifMetadataLossy is called, and this information is preserved in the bytes array, so the two fields are both there. The checkFields method in the JUnit test calls Imaging.getMetadata on the bytes array. The four directories are read and there fields retrieved. However, at this step fields are stored in different object types. The directories are now of type TiffImageMetaData.Directory and the fields are of type TiffMetaData.Item containing a TiffField. Something interesting happens here. When the root directory is parsed, the tag 0x9c9b is correctly identified as XPTITLE (and still contains the "WE à l'étang de Blodelsheim" value) so tagInfo is set to TagInfoXPString and keyword is set to "XPTitle". Something different happens for exif directory, because TifField.getTag(int directoryType, List<TagInfo> possibleMatches) does not accepd XPTITLE for an exif directory type, so it ends up returning TiffTagConstants.TIFF_TAG_UNKNOWN. I did not look any further. I don't know what the most important problem is. It could be that the image contains XPTITLE in the root directory if it does not belongs here. It could be that adding the field to the EXIF directory is wrong and the test should do it in another directory. It could be that adding fields without first checking they are not already in a directory should be avoided. It could be that the tag 0x9c9b for XPTITLE should be recognized in all TiffImageMetaData directories. I don't know what should be done, so I'll let the specialists decide. best regards, Luc > > In any case, the whole TIFF package is full of nonsense and in need of > a rewrite... > > Damjan > > On Thu, Feb 27, 2014 at 4:25 PM, luc <l...@spaceroots.org> wrote: >> Hi, >> >> Trying to run the tests for [imaging] on the current development version, I >> keep getting a failing Junit test. >> >> Failed tests: >> MicrosoftTagTest.testRewrite:77->checkFields:85 expected:<[title]> but >> was:<[WE à l'étang de Blodelsheim]> >> >> Is this failure expected? I am running the tests suite on a Linux computer, >> maybe MicrosoftTagTest is windows-specific? >> >> best regards, >> Luc >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
