Вызов скрипта python и перехват двоичного вывода - PullRequest
Новая
       28

Вызов скрипта python и перехват двоичного вывода

0 голосов
/ 03 октября 2019

Я хочу манипулировать изображением на ходу, и у меня уже есть скрипт на Python, чтобы изменить изображение. Мне нужно только отправить изображение из скрипта Python, чтобы пойти. Для этого я делаю это следующим образом:

Сценарий Python: 

image = image_in_bytes

print (image)

Сценарий Go: 

cmd := exec.Command("python", "image.py")
stdout, err := cmd.StdoutPipe()
if err != nil {
    panic(err)
}
err = cmd.Start()
if err != nil {
    panic(err)
}

body, _ := ioutil.ReadAll(stdout) //I need the image in []byte
cmd.Wait()

Но с приведенным выше кодом golang ждет вечнобез вывода ...

Есть идеи?

1 Ответ

0 голосов
/ 03 октября 2019

Работает безупречно для меня, как описано ниже: 

>>> with open("osx.png","rb") as imageFile:
...     img = repr(imageFile.read())
>>> imageFile.close()
>>> with open("sample.py","w") as pyfile:
...     pyfile.write(img)
>>> pyfile.close()

Затем я вручную отредактировал pyfile, чтобы он выглядел как 

img = '\x89PNG\r\n\x1a\n[remainder skipped for brevity]'
print(img)

Лас, но не в последнюю очередь, я запустил следующий код: 

    cmd := exec.Command("python", "sample.py")
    stdout, err := cmd.StdoutPipe()
    if err != nil {
        panic(err)
    }
    err = cmd.Start()
    if err != nil {
        panic(err)
    }

    body, err := ioutil.ReadAll(stdout) //I need the image in []byte
    cmd.Wait()

    if err != nil {
        log.Fatalf("error reading bytes: %s", err)
    }

    log.Printf("Read %d bytes", len(body))

    o, err := os.OpenFile("img.png", os.O_CREATE|os.O_TRUNC|os.O_WRONLY, 0660)
    if err != nil {
        log.Fatalf("opening img.png: %s", err)
    }
    defer o.Close()
    n, err := o.Write(body)

    if err != nil {
        log.Fatalf("writing image to file: %s", err)
    }
    if n < len(body) {
        log.Fatal("short write")
    }

Полный код, доступный в https://gist.github.com/mwmahlberg/eb47495f68bed4e3cb8073447efdb53d

Полагаю, можно с уверенностью предположить, что в способе хранения данных изображения в файле Python есть что-то странное.

...