Not signed in (Sign In)

Vanilla 1.1.4 is a product of Lussumo. More Information: Documentation, Community Support.

    • CommentAuthorwobbuuu
    • CommentTimeMar 12th 2017 edited
     

    Hello Matthias,

    I found that supposedly there is a bug with renamed *.tif images. It seems like it may be related to the incorrect heading in the file. I found workaround for me using PIL package but I hope you may be interested in this. Code sample below.

    import pya
    import os
    from PIL import Image
    
    directory = os.path.dirname(os.path.realpath(__file__))
    path_tif = os.path.join(directory, "test.tif")
    path_png = os.path.join(directory, "test.png")
    img = pya.Image(path_tif)
    image2 = Image.open(path_tif)
    image2.save(path_png)
    
    img2 = pya.Image(path_png)
    
    flag = False
    for i in range(img.width()):
        for j in range(img.height()):
            if img.get_pixel(i, j) != 0:
                print("Hooray! img")
                flag = True
                break
        if flag:
            break
    
    flag = False            
    for i in range(img2.width()):
        for j in range(img2.height()):
            if img2.get_pixel(i, j) != 0:
                print("Hooray! img2")
                flag = True
                break
        if flag:
            break
    
    os.remove(path_png)
    pya.Application.instance().main_window().current_view().insert_image(img)
    

    File example should be placed in folder containg script sample.

    What is interesting, that when image is inserted it is anyway has right colours.

    Kind regards,

    Anton

    • CommentAuthorMatthias
    • CommentTimeMar 13th 2017 edited
     

    Hi Anton,

    thanks for providing this workaround and for reporting this problem.

    Frankly, I'm not aware of this topic. Can you briefly describe the issue? If I understand it correctly, certain TIF files are not read properly and the solution consists of writing the file to PNG before actually inserting it.

    But then, why is "img" inserted in the last line of code? I had expected to see "img2".

    Thanks,

    Matthias

    • CommentAuthorwobbuuu
    • CommentTimeMar 14th 2017 edited
     

    Hi Matthias,

    I wanted to show you the next thing: when I read one *.TIF image pixel by pixel they all zero, but if I insert it in the layout image is not black (or whatever it should be). The inserting "img" instead of "img2" made to show this phenomena: despite image reading is incorrect it places correct pixel on the layout. Of course in my script I used "img2", because I need correct pixel by pixel reading.

    I suppose this problem connected to the header in the *.TIF file, I don't know exactly but I noticed that it occuries with manually renamed files.

    I know it may be very specific that's why I find workaround firstly and then posted here.

    Regards,

    Anton

    • CommentAuthorMatthias
    • CommentTimeMar 14th 2017
     

    Hi Anton,

    sorry, I think I caused some confusion because of a copy/paste error in the Image class documentation.

    "get_pixel(x,y)" can to be applied to *monochrome" images only. For color images, it will always return 0. To get the pixel values for a color or monochrome image, use "get_pixel(x,y,c)" where c is the color component. To get the green channel which is (approximately) representative for the brightness, use "get_pixel(x,y,1)". This works for color and monochrome images as well.

    Your test case looked monochrome but in fact it was a color image. Hence the issue.

    The documentation says, "get_pixel(x,y)" is for both monochrome and color images. That's wrong. I have corrected this in the master branch.

    Kind regards,

    Matthias

    • CommentAuthorwobbuuu
    • CommentTimeMar 15th 2017
     

    Hi Mattias,

    Well, then my SEM eventually sometimes creates monochrome images and sometimes colored images, I have no idea why, so forget about it..

    Thanks for clarifying this for me,

    Anton