from PIL import Image # pip install pillow

def encode_image( img, msg ):
"""
RGB값으로 구성된 하나의 pixel
"""
length = len(msg)
if length * 3 > len(img.getdata()):
print("문자열이 너무 길어 encode 할 수 없습니다.")
return False
if img.mode != 'RGB':
print("그림은 RGB 모드여야 합니다.")
return False

encoded = img.copy()
width, height = img.size

print("이미지 사이즈 %d x %d" % (width, height))

imgdata = img.getdata()
imgdata = iter(imgdata)

"""    문자 하나(8비트)를 표현하기 위해 3개의 픽셀(9바이트)를 가지고 온다.
픽셀 데이터(9바이트)의 모든 데이터의 마지막 비트는 클리어한다.
9바이트 각각의 마지막 비트에 문자 하나의 데이터를 추가한다.
"""
(x, y) = (0, 0)

for i in range(length):
    pixels = [value & ~1
              for value in next(imgdata)[:3] + next(imgdata)[:3] + next(imgdata)[:3]
              ]
    #print(pixels)
    # 9바이트 픽셀 정보의 마지막 비트는 0
    # 0~7 바이트에  문자 하나(8비트) 값을 설정

    byte = ord(msg[i])

    for j in range(7, -1, -1):
        # 문자의 마지막 비트 값을 j번 픽셀 값에 설정
        pixels[j] |= byte & 1
        # 문자를 오른쪽으로 1비트 쉬프트
        byte >>= 1

    # 이제 9바이트 중 하위 8바이트의 마지막 비트에 문자 정보가 추가되었음

    # 문자열을 모두 숨겼으면, 픽셀 데이터의 9번째 데이터의 마지막 비트를 셋팅
    # 디코딩 시 9번째 데이터의 마지막 비트가 1로 설정되어 있을 때 까지 디코딩
    if i == length - 1:
        pixels[-1] |= 1

    rgb1 = tuple(pixels[0:3])
    rgb2 = tuple(pixels[3:6])
    rgb3 = tuple(pixels[6:9])

    # 복사본 이미지의 해당 픽셀 위치에 값을 지정
    # 이 코드는 width가 3의 배수 인 경우만 제대로 동작
    encoded.putpixel( (x, y), rgb1 )
    encoded.putpixel( (x + 1, y), rgb2 )
    encoded.putpixel( (x + 2, y), rgb3 )
    if x + 2 == width - 1:
        x = 0
        y += 1
    else:
        x += 3

return encoded

def decode_image( image ):
imgdata = image.getdata()
imgdata = iter( imgdata )

hidden_msg = ''

if row == 0 and col == 0:
     length = r
elif index <= length:
     hidden_msg += chr(r)
     index += 1
 return hidden_msg:

#while True:
    # 이미지에서 9바이트씩 가져와서 처리

    # 0~8 바이트에 숨겨진 8비트를 추출

    # 추출된 문자는 hidden_msg에 추가

    # 마지막 9번째 픽셀 정보가 1이면 종료

#return hidden_msg

이미지 파일 오픈

img_file = "Lenna.png"
img = Image.open(img_file)

print(img, img.mode)

원본 보호를 위해 enc 파일 생성

encoded_img_file = "enc_" + img_file

secret_msg를 이미지에 인코딩

secret_msg = "Hello python world!!"
img_encoded = encode_image( img, secret_msg )

if img_encoded:
img_encoded.save( encoded_img_file )
print("저장되었습니다.")

인코딩된 이미지 파일을 오픈

img2 = Image.open( encoded_img_file )

디코딩된 문자열 출력

print(decode_image( img2 ))

Hoisting from the todo issue, as this is now getting critical.

Hoisting from python-pillow/Pillow#2761 (comment)

We're not getting coverage from Docker builds.

There's some divergence already with lcov (eg. CentOS 6):

Setting up lcov (1.10-1build1) ...
Setting up libgd-gd2-perl (1:2.46-3.1build1) ...
Capturing coverage data from .
Found gcov version: 4.8.4
Scanning . for .gcda files ...
geninfo: ERROR: no .gcda files found in .!

Versus (eg. native Python 2.7):

Setting up lcov (1.10-1build1) ...
Setting up libgd-gd2-perl (1:2.46-3.1build1) ...
Capturing coverage data from .
Found gcov version: 4.8.4
Scanning . for .gcda files ...
Found 1 data files in .
Processing _webp.gcda
Finished .info-file creation

One thing: Docker and native both run the after_success.sh script (which collates and sends coverage data off) but not install.sh or script.sh (in which Pillow is built with the coverage switch).

Are the Dockers built with lcov/CFLAGS="-coverage"?

Where is the Pillow build defined for Docker?

https://blog.alexellis.io/docker-is-deleting-open-source-images/

I don't think we're directly affected by this, because IIRC the pillow docker account is setup as a personal account, but we may have to think about rehosting onto github.

More context:

docker/hub-feedback#2314

https://news.ycombinator.com/item?id=19763413

@wiredfool Do we need to reset the password and update this?

So, a bit of history here -- these images were originally setup to have a better diversity of tests than we were getting with travis at the time. They're primarily for testing the current master + PRs against a range of distro supplied versions of our dependencies, as well as some 'alternate' features that we're not likely to get natively (i.e. arch and valgrind). The original bit of testing against Pillow was for ensuring that we're not going to break the build by throwing in docker images that weren't tested.

So, given the current state of this repo, and the PRs against it, I think that:

1. It doesn't really make sense to test against stable
2. We should have the 'master' branch be the one that determines which images can be pushed to dockerhub.

Why not stable?

Well, frankly, we basically never test anything against stable in the base repo. It's always master or master+ PR. The only time we ever test against something derived from stable is on point releases, and then I'd argue that we should generally be passing whatever docker changes are in place. So why test them? They don't tell us anything useful, and they're slow.

Why master?

The point of the latest PRs is to improve coverage of tests, either by expanding the diversity of architectures or the diversity of what we're testing for. Since the point here is that there were errors on stable that are now ignored/fixed in master, having the success of the PR gated on passing stable is pretty much irrelevant.

This has held up both the alternate arch PR and the valgrind PR, and I don't see that the extra effort or burned electrons is gaining us anything.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

if i want to use this kind of transform color with option ImageCms.INTENT_ABSOLUTE_COLORIMETRIC,how to code it ?

Originally posted by @digital-prepress in python-pillow/Pillow#6161 (comment)

• Docker hub upload on success after push to master
• Test on py3 as well as py2 on all platforms where it's available.
• pull test.sh out into the source directory instead of inline in the Dockerfile

The build has started failing, as these cron builds show:

Last good, 2018-0-08: https://travis-ci.org/python-pillow/docker-images/builds/413480462
First bad, 2018-0-08: https://travis-ci.org/python-pillow/docker-images/builds/416270292

=================================== FAILURES ===================================
_______________________ TestFileEps.test_bytesio_object ________________________
self = <test_file_eps.TestFileEps testMethod=test_bytesio_object>
    def setUp(self):
>       if not EpsImagePlugin.has_ghostscript():
Tests/test_file_eps.py:25: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
build/bdist.linux-x86_64/egg/PIL/EpsImagePlugin.py:63: in has_ghostscript
    ???
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
popenargs = (['gs', '--version'],)
kwargs = {'stdout': <closed file '/dev/null', mode 'wb' at 0x7f5e448fde40>}
retcode = 1, cmd = ['gs', '--version']
    def check_call(*popenargs, **kwargs):
        """Run command with arguments.  Wait for command to complete.  If
        the exit code was zero then return, otherwise raise
        CalledProcessError.  The CalledProcessError object will have the
        return code in the returncode attribute.
    
        The arguments are the same as for the Popen constructor.  Example:
    
        check_call(["ls", "-l"])
        """
        retcode = call(*popenargs, **kwargs)
        if retcode:
            cmd = kwargs.get("args")
            if cmd is None:
                cmd = popenargs[0]
>           raise CalledProcessError(retcode, cmd)
E           CalledProcessError: Command '['gs', '--version']' returned non-zero exit status 1
/usr/lib64/python2.7/subprocess.py:190: CalledProcessError
----------------------------- Captured stderr call -----------------------------
gs: /usr/lib/libc.so.6: version `GLIBC_2.28' not found (required by /usr/lib/libgs.so.9)

We discussed this on another issue (PR?) recently, but I can't find it now.

Some Linux distributions are making use of PEP 668 to isolate system and user/pip environments:

• https://peps.python.org/pep-0668/

Existing images should be fine, but this will likely affect some future images. A few solutions are suggested in:

• https://pythonspeed.com/articles/externally-managed-environment-pep-668/

This repo would be a good candidate to test using Azure Pipelines GitHub Actions. We have 24 jobs and AP gives 10 GHA gives 20 parallel builds. Travis CI only gives 5.

The main python-pillow/Pillow repo's AP GHA config can be used as a basis, it's running the Docker tests.

• https://github.com/python-pillow/Pillow/blob/master/azure-pipelines.yml
• https://github.com/python-pillow/Pillow/blob/master/.azure-pipelines/jobs/test-docker.yml
• https://github.com/python-pillow/Pillow/blob/master/.github/workflows/test-docker.yml

AP GHA now has cron too:

https://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml

https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#onschedule

Once done, we can either remove or cut down the .travis.yml to a minimal, fast set (to finish quicker than AP GHA); as a backup and because it's an easy and more familiar thing for contributors to enable.