png-mng-misc — Discussion of PNG and MNG spec issues, software (as user, not programmer!), etc.

[png-mng-misc] Location of eXIf chunk

[Phil H. <ph...@ow...>]

Although the original eXIf specification didn't mandate a location for the eXIf chunk, web developers are advising to ignore the eXIf if it comes after IDAT:

https://github.com/w3c/csswg-drafts/issues/4929

As such, you may want to consider amending the specification to reflect this.  Minimally, it should be recommend to place eXIf before IDAT for web compatibility.  Or possibly requiring it to come before IDAT.

	- Phil Harvey

[png-mng-misc] PNG difftool/mergetool for git?

[Soni L. <fak...@gm...>]

Not sure if anyone still reads this list, but...

It would be useful if PNG had a chunk type for difftools/mergetools to
use, in particular git difftools/mergetools, so that PNGs can be checked
into git and later diffed and merged. In particular, in case of merge
conflicts, a PNG should be able to contain all the conflicting data. Oh
yeah, the tool would also be responsible for identifying what counts as
a merge conflict, so some sort of configuration would be useful.
(perhaps in-band, with another chunk? seems unnecessarily complicated
tho, out-of-band would be more flexible and more useful.)

[png-mng-misc] New chunk for CICP values

[Chris L. <ch...@w3...>]

This was sent to png...@w3..., which used to forward here, but I 
haven't seen the message go by.

Hi Everyone,

I would like to suggest that we add a “chunk” to PNG which includes MPEG-ITU-ISO (ISO/IEC 23091) CICP value chunks to PNG.

This will provide a method for still graphics to identify the format of the image which conforms with broadcast and cinematic presentation formats.

All the best,

___________________________________

Chris Seeger
Director, Advanced Content Production Technology
Office of the CTO
NBCUniversal, LLC

-- 
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media

[png-mng-misc] PNGs with a remarkable size/quality relation

[Jens K. <ko...@ma...>]

Hi

Is there a site related to PNGs with a remarkable size/quality relation
like the PNG Gradient [1]?
Special size limits could be 725 bytes for the face header in mails
[2] or (1K/)4K/16K/64K like demos have.
If I search for "png small compression" I get many sizes offering
services for recompressing PNGs

Greets

Jens


[1] Source of PNG Gradient:
https://upload.wikimedia.org/wikipedia/commons/8/89/PNG-Gradient.png
[2] https://quimby.gnus.org/circus/face/

[png-mng-misc] libmng build error on ppc64le

[<png...@al...>]

Hello list!

I'm trying to build libmng on a ppc64le Linux machine without success.

Relevant build log:

    checking build system type... ./config.guess: unable to guess system
    type

    This script, last modified 2012-12-29, has failed to recognize
    the operating system you are using. It is advised that you
    download the most up to date version of the config scripts from

    http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
    and
    http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD

    If the version you run (./config.guess) is already up to date, please
    send the following data and any information you think might be
    pertinent to <con...@gn...> in order to provide the needed
    information to handle your system.

    config.guess timestamp = 2012-12-29

    uname -m = ppc64le
    uname -r = 4.19.82-gentoo
    uname -s = Linux
    uname -v = #3 SMP Thu Nov 28 16:37:22 CET 2019

    /usr/bin/uname -p = POWER9, altivec supported
    /bin/uname -X     =

    hostinfo               =
    /bin/universe          =
    /usr/bin/arch -k       =
    /bin/arch              =
    /usr/bin/oslevel       =
    /usr/convex/getsysinfo =

    UNAME_MACHINE = ppc64le
    UNAME_RELEASE = 4.19.82-gentoo
    UNAME_SYSTEM  = Linux
    UNAME_VERSION = #3 SMP Thu Nov 28 16:37:22 CET 2019
    configure: error: cannot guess build type; you must specify one
    make: *** [Makefile:384: config.status] Error 1

There is also a related Gentoo Bugzilla report: 
https://bugs.gentoo.org/668676

Re: [png-mng-misc] Register bAYR Publicly Draft

[Cosmin T. <co...@cs...>]

On Sat, 16 Nov 2019 at 06:47, Marcus Johnson wrote:
> I’m proposing to publicly register the bAYR chunk, which adds support for RAW images to the PNG specification.

Hello, Marcus, and thank you for your proposal.

> It is entirely backwards compatible with previous PNG standards.

TL/DR: It won't work, for many reasons.

>From what I know about the Bayer image representation, yes it has RGB
image data in common with PNG, but it is otherwise incompatible with
PNG in many ways. For that specific purpose, Adobe DNG is an
interchangeable format that is much more suitable.

There are many complexities associated with Bayer. For bit depths,
typical values are 10-bit and 12-bit. They can be higher, all the way
to 16-bit (for *very* expensive cameras, mind you), but the idea
behind DNG compression is that they are efficiently represented due
DNG's algorithms, suited by that kind of image data. The PNG
representation is, on the other hand, suboptimal, at 16-bit only,
which is enforced by the inner workings of the zlib compression. With
that consideration alone, and presuming that everything else would
work (although, spoiler alert, it doesn't): why would anybody prefer
PNG over DNG?

Even more importantly, most-importantly perhaps, you have the
following fundamental limitation: storing the average between two
greens in IDAT, plus the difference in a fDAT-like chunk, is asking
for trouble. If you place the difference in an ancillary chunk, you
risk losing 50% of your green channel -- big No-No from photographers.
And if you place the difference in a newly-invented critical chunk,
you break PNG -- big No-No from our group.

For the above-mentioned reasons, Bayer image representation is a
non-starter for PNG. There is no good choice available: only a bunch
of bad choices.

And there's more.

For example, DNG accounts for the fact that lens manufacturers may opt
to leave some of their "digital" lenses optically-uncorrected, as a
deliberate design choice. AFAIK virtually all mirrorless mounts allow
that. And virtually all point-and-shoot cameras capable of wide-angle,
too. The lens distortion parameters (barrel, pincushion, moustache,
etc., with their specific details and metrics) may be encoded into the
lens, transmitted via the lens contacts from the lens to the camera,
and encoded into the EXIF. The DNG-aware decoders will then apply the
"inverse distortion" transformation, effectively linearizing the
image.

And you have a licensing problem here. The linearization step is not
an option if the manufacturer says so. (And to the best of my
knowledge, all manufacturers say so: none of them want their users to
end up getting distorted photos, either accidentally or
intentionally.) I'm aware that some DNG image processors allow the
users to disable distortion correction, e.g. to improve sharpness, or
for some artistic effect. But I'm not so sure about the legitimacy of
that option, as far as DNG licensing is concerned.

My point: distortion correction would have to be a critical chunk,
too, if it were to be encoded in PNG. And leaving aside the virtually
impossible logistics of introducing a new critical chunk: such a
critical chunk would be a pretty darned complicated one, imposing a
pretty heavy burden on all PNG decoders.

So even if we'd have started PNG from scratch today, it still wouldn't
work, unless you'd make it extra-complicated and burdened with
licensing restrictions. And you already have something for that,
anyway: you have DNG.

Last but not least, the Bayer color channels are not co-sited, but
alternating in a pattern. (The Bayer pattern.) However, the PNG color
channels are co-sited: every RGB pixel is R-G-B on top of one another.
The rendered Bayer images may look "ok-ish" at low resolution, but I
expect them to become ugly (or at least "not nice") at full
resolution. Sigma Foveon (excluding Foveon Quattro) is the only
digital photography equivalent that would come even close to that RGB
representation -- "close but no cigar" because Foveon, too, requires
an additional kind of processing that just doesn't exist in the world
of PNG.

The only digital photography option remaining?... Leica Monochrom, anyone?...

>From where I stand, Leica Monochrom is the only digital camera whose
output *may* be well-suited for PNG representation. I have yet to see
a Leica Monochrom camera in real life, and/or to meet a Leica
Monochrom photographer. That will sure be an interesting encounter.

Sincerely,
Cosmin

[png-mng-misc] Proposal Template

[Marcus J. <bum...@gm...>]

Is there a generic template for proposing new public chunks?

[png-mng-misc] Register bAYR Publicly Draft

[Marcus J. <bum...@gm...>]

I’m proposing to publicly register the bAYR chunk, which adds support for RAW images to the PNG specification.

It is entirely backwards compatible with previous PNG standards.

First, let’s talk about the name.

The name comes from the Bayer filtering commonly used in camera sensors to take the 1 red, 1 blue, and 2 green photosites into the commonly used red, green, and blue channels for an image.

The goal with the chunk name is to represent this relationship within PNG’s four character chunk naming convention.

And to specify to decoders that this chunk is publicly registered, and it should be copied by default unless the image has been edited, and then it must be discarded if it can’t be regenerated.

I’m a little confused about the naming convention though, so if I used the wrong spelling of the chunk name please inform me of this.

How it works:

Encode: 
Green1 and Green2 are to be added together, modulo 2^BitDepth (256 for 8 bit, 65536 for 16 bit, etc) and this average is to be stored as the green value for each pixel in the RGB stream within the iDAT/fDAT chunks.

A difference signal is to be calculated as follows within the bAYR chunk as a zlib compressed stream.

The difference signal is calculated as follows:

(Green1 - Green2) % 2^BitDepth

Decode:

Green1 = ((Green + bAYR) / 2) % 2^BitDepth

Green2 = ((Green - bAYR) / 2) % 2^BitDepth.

Decoders that do not support the bAYR chunk will still decode the averaged Green channel within the regular image stream, and it won’t look any different than if the camera it’s self had averaged the green channels as part of demoisaicing.

[png-mng-misc] Questions about MNG

[Soni L. <fak...@gm...>]

Hi! I'm interested in using MNG in my game, but I have a few questions:

Does MNG support overlapping layers and still images with those 
overlapping layers?

If not, would it be possible to have it added?

Does MNG support linking text to colors? (e.g. mapping colors to text)

If not, would it be possible to have it added?

My plans basically involve using MNG for GUI layouts. This basically 
means having an MNG called "layout.mng" containing layers like 
"background", "foreground" and "overlay", then using colors to represent 
UI elements and images (e.g. the background layer could be a solid color 
that references a background image "background.png"). UI elements would 
be further MNGs and so on until either code or an image is reached.

Thanks.

Re: [png-mng-misc] png image scrambled

[Roland W. <wi...@gn...>]

On Sat Aug 24 2019 Bob Friesenhahn wrote:
> The overlay of a transparent image on a background is not a function 
> of libpng.  This is something that GNU Emacs would need to do while 
> rendering the image for display. If GNU Emacs was displaying a web 
> page, then I would assume it should use the background color that the 
> web page indicates.

Sure! -- GNU Emacs already comes with pretty much all of this
infrastructure.  It turns out the problem was that emacs did not
handle properly the tRNS chunk data for paletted PNG images.  In the
meanwhile, some emacs maintainers that are more familiar with the
emacs image code than myself have come up with a patch for this that
has about twenty lines in order to do the right thing.

Thanks again for pointing us in the right direction.

Re: [png-mng-misc] png image scrambled

[Bob F. <bfr...@si...>]

On Fri, 23 Aug 2019, Roland Winkler wrote:

> For GNU Emacs customizability is quite important.  So it seems to me
> it would make sense that it allowed the user to choose a custom
> color for transparent parts of a png image similar to eog.  I'll
> discuss this on an emacs mailing list.  I assume that libpng
> supports this.

The overlay of a transparent image on a background is not a function 
of libpng.  This is something that GNU Emacs would need to do while 
rendering the image for display. If GNU Emacs was displaying a web 
page, then I would assume it should use the background color that the 
web page indicates.

Bob
-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: [png-mng-misc] png image scrambled

[Roland W. <wi...@gn...>]

On Fri Aug 23 2019 Pavel Zlatovratskii wrote:
> It's not looks like a bug in libpng and not corrupted image.
> 
> Your image use fully transparent black as background using tRNS
> chunk. Some software use neutral (grey or white) background and
> image looks good. Other ignore transparency (and they are allowed
> to do so as tRNS is an ancillary chunk) and draw background with
> original black colour.
> 
> You can check modified picture: three bytes black to white and
> four bytes of CRC changed.

Thanks a lot to everyone who replied to this thread.  Now I
understand much better how the problem comes about.

The eog viewer lets the user choose a custom color for transparent
parts.  So with eog I happened to get for this picture what I was
expecting to get because my eog was configured to use a white
background.  If I choose black instead, the figure is as "scrambled"
as what I got from rpng.

For GNU Emacs customizability is quite important.  So it seems to me
it would make sense that it allowed the user to choose a custom
color for transparent parts of a png image similar to eog.  I'll
discuss this on an emacs mailing list.  I assume that libpng
supports this.

Re: [png-mng-misc] png image scrambled

[Pavel Z. <sc...@ya...>]

It's not looks like a bug in libpng and not corrupted image.

Your image use fully transparent black as background using tRNS chunk. 
Some software use neutral (grey or white) background and image looks 
good. Other ignore transparency (and they are allowed to do so as tRNS 
is an ancillary chunk) and draw background with original black colour.

You can check modified picture: three bytes black to white and four 
bytes of CRC changed.

23.08.2019 17:45, Roland Winkler:
> The attached png image is not displayed correctly, and I am trying
> to find out the cause of this.
>
> I am not a png expert.  I ran into this because GNU Emacs (that uses
> libpng) does not display this image as expected, unlike other
> applications including eog and imagemagick.
>
> Then I built the test program rpng.  It displays this image in the
> same scrambled way as emacs.  Is this due to a corrupted image (that
> other applications handle more graciously) or is this a bug in libpng?
>
> Thanks.
>
>
>
> _______________________________________________
> png-mng-misc mailing list
> png...@li...
> https://lists.sourceforge.net/lists/listinfo/png-mng-misc

-- 
Have a nice DOS.

Pavel Zlatovratskii sc...@ma...; sc...@ya...

Re: [png-mng-misc] png image scrambled

[Dustin O. <mys...@gm...>]

Even if Emacs agrees with it?



Dustin

On Fri, Aug 23, 2019, 12:57 Bob Friesenhahn <bfr...@si...
wrote:

> On Fri, 23 Aug 2019, Roland Winkler wrote:
>
> > The attached png image is not displayed correctly, and I am trying
> > to find out the cause of this.
> >
> > I am not a png expert.  I ran into this because GNU Emacs (that uses
> > libpng) does not display this image as expected, unlike other
> > applications including eog and imagemagick.
>
> Are you saying that eog and imagemagick appear to display the image
> correctly?  I looked at it with GraphicsMagick and it does not look
> "scrambled", although the image is very tiny so it is difficult to
> look at without magifying it.
>
> > Then I built the test program rpng.  It displays this image in the
> > same scrambled way as emacs.  Is this due to a corrupted image (that
> > other applications handle more graciously) or is this a bug in libpng?
>
> The probability that this is due to a bug in libpng is exceedingly low
> since it likely has a billion users.
>
> It may be that there is a problem with how the test program was
> compiled and linked.
>
> Bob
> --
> Bob Friesenhahn
> bfr...@si..., http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
> Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt
>
>
> _______________________________________________
> png-mng-misc mailing list
> png...@li...
> https://lists.sourceforge.net/lists/listinfo/png-mng-misc
>

Re: [png-mng-misc] png image scrambled

[Bob F. <bfr...@si...>]

On Fri, 23 Aug 2019, Roland Winkler wrote:

> The attached png image is not displayed correctly, and I am trying
> to find out the cause of this.
>
> I am not a png expert.  I ran into this because GNU Emacs (that uses
> libpng) does not display this image as expected, unlike other
> applications including eog and imagemagick.

Are you saying that eog and imagemagick appear to display the image 
correctly?  I looked at it with GraphicsMagick and it does not look 
"scrambled", although the image is very tiny so it is difficult to 
look at without magifying it.

> Then I built the test program rpng.  It displays this image in the
> same scrambled way as emacs.  Is this due to a corrupted image (that
> other applications handle more graciously) or is this a bug in libpng?

The probability that this is due to a bug in libpng is exceedingly low 
since it likely has a billion users.

It may be that there is a problem with how the test program was 
compiled and linked.

Bob
-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt

[png-mng-misc] png image scrambled

[Roland W. <wi...@gn...>]

The attached png image is not displayed correctly, and I am trying
to find out the cause of this.

I am not a png expert.  I ran into this because GNU Emacs (that uses
libpng) does not display this image as expected, unlike other
applications including eog and imagemagick.

Then I built the test program rpng.  It displays this image in the
same scrambled way as emacs.  Is this due to a corrupted image (that
other applications handle more graciously) or is this a bug in libpng?

Thanks.

Re: [png-mng-misc] Need PNG/MNG/JNG help in GraphicsMagick

[Nancy Randers-P. <na...@co...>]

On 06/28/2019 10:48 AM, Bob Friesenhahn wrote:
> Since Glenn has departed from this earth (and the raphicsMagick 
> project), we could really use a PNG expert to provide the 
> GraphicsMagick project with expert advice and perhaps even help with 
> implementing source code.  I am able to work on most security issues 
> pertaining to the PNG module but lack the PNG expertise and time to 
> finish the parts which are not quite what they should be.
>
> Please let me know if you are interested in helping.
>
> Thanks,
>
> Bob

Thank you, Nancy Randers-Pehrson


-- 
Nancy M. Randers-Pehrson
na...@co...
443-866-7263 (cell)

[png-mng-misc] Need PNG/MNG/JNG help in GraphicsMagick

[Bob F. <bfr...@si...>]

Since Glenn has departed from this earth (and the raphicsMagick 
project), we could really use a PNG expert to provide the 
GraphicsMagick project with expert advice and perhaps even help with 
implementing source code.  I am able to work on most security issues 
pertaining to the PNG module but lack the PNG expertise and time to 
finish the parts which are not quite what they should be.

Please let me know if you are interested in helping.

Thanks,

Bob
-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: [png-mng-misc] Farewell, Glenn Rander-Pehrson

[Cosmin T. <co...@cs...>]

Christoph Päper wrote:
> Those have been sad news. However, life goes on and I see that Cosmin Truta has taken over maintenance of [libpng], but does anyone (want/plan to) continue Glenn's work on [pngcrush] (and related tools) or is [OptiPNG] the future?

There are still a few remaining issues with libpng, which I would like
to resolve first. After that, my plan is to continue with both libpng
and OptiPNG maintenance, in parallel. I have no specific plans for
pngcrush, though.

If someone else wants to take over pngcrush, or even OptiPNG, that'd be great.

Bob Friesenhahn wrote:
> Is pngcrush no longer working or otherwise known to need maintenance?

About keeping pngcrush functional while libpng is continually updated,
the responsibility is on libpng's side. I definitely want to preserve
backwards compatibility in libpng as much as possible, and ideally not
break libpng-using applications.

About fixing defects specific to pngcrush, if there are or will be
any, or adding new features, etc., a new maintainer would be highly
appreciated.

Sincerely,
Cosmin

Re: [png-mng-misc] Farewell, Glenn Rander-Pehrson

[Bob F. <bfr...@si...>]

On Fri, 14 Jun 2019, Christoph Päper wrote:

> Cosmin Truta <ct...@gm...> 2018-10-22:
>>
>> I am deeply saddened to inform you that Glenn Randers-Pehrson, our
>> long-time group lead, passed away last weekend, following a long and
>> painful illness.
>
> Those have been sad news. However, life goes on and I see that 
> Cosmin Truta has taken over maintenance of [libpng], but does anyone 
> (want/plan to) continue Glenn's work on [pngcrush] (and related 
> tools) or is [OptiPNG] the future?

Is pngcrush no longer working or otherwise known to need maintenance?

Bob
-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: [png-mng-misc] Farewell, Glenn Rander-Pehrson

[Christoph P. <chr...@cr...>]

Cosmin Truta <ct...@gm...> 2018-10-22:
> 
> I am deeply saddened to inform you that Glenn Randers-Pehrson, our
> long-time group lead, passed away last weekend, following a long and
> painful illness.

Those have been sad news. However, life goes on and I see that Cosmin Truta has taken over maintenance of [libpng], but does anyone (want/plan to) continue Glenn's work on [pngcrush] (and related tools) or is [OptiPNG] the future?

[libpng]: http://www.libpng.org/pub/png/libpng.html
[pngcrush]: https://pmt.sourceforge.io/pngcrush/
[OptiPNG]: http://optipng.sourceforge.net/

Re: [png-mng-misc] Location of XMP in PNG image

[Phil H. <ph...@ow...>]

Hi Cosmin,

Thanks for your feedback.

> On Apr 12, 2019, at 8:00 AM, Cosmin Truta wrote:
> 
> If Photoshop is ignoring XMP trailing IDAT, that's a bug.
> 
> File a bug report, perhaps?

Right.  I would do this but I can't confirm that the bug
still exists in the current version of Photoshop because
my trial period has expired.

(People like me who are averse to paying for
subscription-based software are locked into using an
older version.)

	- Phil

Re: [png-mng-misc] Location of XMP in PNG image

[Cosmin T. <co...@cs...>]

On Thu, 11 Apr 2019 at 09:00, Phil Harvey wrote:
> In a PNG image, the XMP uses an iTxt chunk, which according
> to my reading of the specification may occur anywhere before
> IEND.  Is this correct?

Yes, it is correct that iTXt may appear anywhere. Applications may
impose additional restrictions on the chunk's content, and are free to
ignore such content as they please, but that is not the case with XMP.

> The XMP specification states:
> "Encoders are encouraged to place the chunk at the beginning
> of the file, but this is not required."

Indeed.

> But a single-pass metadata editor (such as ExifTool) must
> write the XMP as late a possible to avoid the possibility
> of writing duplicate or conflicting metadata.  As a result,
> by default ExifTool writes the XMP chunk just before IEND.

This is an understandable restriction.

> The problem is that Photoshop seems to ignore XMP if it
> comes after the IDAT chunk, but as far as I know this
> should be perfectly valid.

This is very unfortunate, especially considering that the XMP support
in PNG had been drafted and proposed to our group by somebody from
Adobe.

I understand the desire to place the metadata at the beginning,
considering that it can be inspected without the need to load or
download the whole image file. Especially if that image is coming on a
wire, or if random file access is otherwise unavailable. But that's a
non-normative recommendation. If Photoshop is ignoring XMP trailing
IDAT, that's a bug.

File a bug report, perhaps?

Sincerely,
Cosmin

[png-mng-misc] Location of XMP in PNG image

[Phil H. <ph...@ow...>]

In a PNG image, the XMP uses an iTxt chunk, which according
to my reading of the specification may occur anywhere before
IEND.  Is this correct?

The XMP specification states:

"Encoders are encouraged to place the chunk at the beginning
of the file, but this is not required."

But a single-pass metadata editor (such as ExifTool) must
write the XMP as late a possible to avoid the possibility
of writing duplicate or conflicting metadata.  As a result,
by default ExifTool writes the XMP chunk just before IEND.

The problem is that Photoshop seems to ignore XMP if it
comes after the IDAT chunk, but as far as I know this
should be perfectly valid.

- Phil

[png-mng-misc] First image of a black hole in full-resolution PNG format

[Cosmin T. <ct...@gm...>]

Hello, everyone,

In celebration of the publication of the first photo of a black hole,
I am making this photo available in full-resolution, 30 megapixels
RGB48 PNG. If anybody needs a large, metadata-rich, publicly-available
PNG reference test image, this could serve that purpose.

7416x4320 pixels, 3x16 bits/pixel, RGB
https://bitbucket.org/ctruta/space/src/master/eso1907a.png

I converted this PNG image from TIFF using OptiPNG, and I optimized it
further using ZopfliPNG. I updated its metadata using Exiftool.

The original image is available in various formats, including
high-resolution uncompressed RGB TIFF, on the ESO website:
https://www.eso.org/public/images/eso1907a/

Enjoy!
Cosmin