PNG-48 (16bit) not working

[alejandrojapkin]

PNG-48 produce different types of artifacts and will transform an actual photograph into close-to random pixels on canvas. Here attached a resize from 720p to 1080p. Interesting error / truncation. Actual photographs produce bizarre anisotropic noise among other artifacts.

[avaneev]

Sorry for the issue. I use PNG library for PNG-48 support, there seems to be some format issues within this library. Can you post a color PNG-48 file so I can check it out?

[alejandrojapkin]

Here are a successful example and a failed one. Notice that the successful example was originally a jpeg converted to 16 bit png for the purpose of testing avir over PNG48, and the failed one is a magiclantern DNG converted to PNG48, both using Photoshop CS6. In both cases, the original dpi resolution was 800 and the output is 72 which puzzles me since the purpose of the tool is to enhance an image. For your consideration:

Successful cases:

Last minute notice: Github won't let me upload the latter images. They're over 10mb in size. Take that as a hint.

[avaneev]

Could you please upload somewhere the original PNG-48 image which does not convert correctly? I do not need the result of conversion, just need the original file you are trying to convert.

DPI is currently not scaled together with the image, it is set to default 72 DPI, I will try to fix this.

[alejandrojapkin]

This is an example file, though all my real 16bit color images showed similar problems. Download an example here http://expirebox.com/download/abc263a3179527390ed77af6f743298a.html

Please click on this second link to delete the image once you successfully downloaded it. http://expirebox.com/delete/1a5af6272c7504eeb87434b6c64f45b8.html

As for the DPI, likely you want your pipeline to be the lesser destructive possible. It'd be very interesting to test with a LUT perhaps the color fidelity of your conversion vs another method for image enlargement.

[avaneev]

Thanks, I'll fix this issue soon, together with correct DPI scaling. Note that AVIR's "imageresize" does not perform gamma linearization, so the color results may be unexpected in comparison to other tools with gamma linearization. AVIR was generally designed to be used as a C++ library, with the developer responsible for any color corrections, while the "imageresize" tool is only a demonstration, I had no plans to add extended functionality to it.

[avaneev]

I have plans to add the built-in gamma linearization at a later time.

[alejandrojapkin]

There are a few interesting GL enabled gamma linearization libraries around github. I understand the goals of imageresize as a tool, my concern is that its limitations are cornering its demonstration capabilities of the AVIR lib. The bottom line is that gamma linearity and dots per inch happen to be just as important means to assess the quality of an enlargement method, so I suggest to try and implement these if it's possible to you.

For the specific case of this issue, I notice that the image I wanted to scale was over 10mb in size, had real 16 bit colors, was re encoded using Adobe RGB gamma, and came from a DNG source.

[avaneev]

I've fixed PNG-48 handling and DPI scaling.

[alejandrojapkin]

OK. I can perform some testing. Is it compiled into the current imageresize for OSX?

[alejandrojapkin]

That's a no go here. Problem still present with images of actual 16 bit color depth using OSX binary for commit: https://github.com/avaneev/avir/commit/000fc4a73d726ce778ba1965b57c078811a4bc27 Access to example here: http://expirebox.com/download/1ea4547525fc0acc8f6f27ab9d8e3812.html Click here to delete later: http://expirebox.com/delete/2c749717b2963eef65a53f36a0035d08.html

[avaneev]

Are you on Mac, Windows, or Linux? The conversion works correctly on Windows. I've opened the converted file in GIMP without an issue.

[alejandrojapkin]

As stated above this was tested on OS X Mac . Please do check that you're working on the untainted 16 bit file I uploaded, with no modifications. Did you successfully enlarge my image on windows? To 1080p?

[avaneev]

Yes, I can reproduce the issue on OS X. No such issue on Windows and Linux, though. Seems like some PNG library issue, I'll try to find a fix.

[alejandrojapkin]

I see. Is imageIO getting the dimensions fed correctly ? Openimageio sounds like a good basis to achieve gamma linearity by the way. Perhaps you can even output to a log-ish gamma to offer more dynamic range to sharpen from

[avaneev]

The problem is in 16-bit endianness - due to unknown reason libPNG inverts it on Mac, maybe it's due to some old PowerPC assumption.

I plan to add a built-in gamma correction, it's better that way because it will be multi-threaded. Gamma linearization is a hefty operation - requires math power raising.

[avaneev]

OK, I've fixed the issue with PNG-48 on OS X.

[avaneev]

I've also added the sRGB gamma correction.

[alejandrojapkin]

What is the current gamma output?

[alejandrojapkin]

I confirm that the imageresize tool is working for OS X Mac. On Mavericks 10.9.5 2.3Ghz i7 I was able to produce a 3840x2160 image from the same original as before in 4.0927 sec Please provide some specs on the gamma output and you may close this one.

[avaneev]

It assumes input is in sRGB gamma, so the output is in sRGB as well.

[alejandrojapkin]

So it would be a good idea to take all images to sRGB gamma prior to using the tool, for the case of rec.709 gamma as an example.

[avaneev]

Well, yes, if you want to use this tool for some mass conversions you'll need to provide sRGB gamma. I have no plans to support any other gammas. Note that if PNG contains the gAMA chunk, the image will be auto-converted to 2.2 gamma which is very close to sRGB anyway.

[alejandrojapkin]

I'm experiencing differences in color grading so I would definitely opt for converting back and forth to sRGB <-> rec.709, since the latter has not a fixed gamma and may not be 2.2

[alejandrojapkin]

The gamma correction is not producing very faithful results, though. I'm picking up a very subtle greenish haze on an image I just enlarged; color seems slightly distorted unfortunately. Perhaps because the RGB gamma of my source image is not true sRGB.

[avaneev]

My suggestion then is to convert to linear gamma, then resize using --gamma=false setting, and then convert back to your preferred gamma.

[avaneev]

As for the "greenish haze", AVIR is completely neutral to channels, it does not give any weight to either channel. However, when comparing original and resized images you should make sure no intermediate resizing takes place. This is especially true if you resize to print resolutions like 6000x4000 - unless you have a screen with such resolution you won't be able to see the whole image without intermediate resizing. Also if you examine resized image one part at a time you may experience local examination limitations - e.g. when you see the whole image the haze may not be so apparent in comparison to looking closer to the parts of the image.

Then again, sRGB gamma may not be what you are looking for.

[avaneev]

It is also possible that the way I linearize the gamma in "imageresize" is not completely correct. Currently, the gamma is applied to each channel separately. However, I may need to convert all 3 channels to luminance first and then apply gamma to this luminance, and then correct the channels. I'm not getting comprehensive explanations on the web, most sources apply gamma to individual channels as well. Also there is no universal formula to convert RGB to luminance exists: various sources give different weights to the channels.

[alejandrojapkin]

The haze I refer to was very light and distributed around the picture unevenly. I must clarify, tho, that it was only visible to a trained eye. Then again, users interested in efficient resizing are likely the type of user who will notice such problem. My picture was indeed in some sRGB profile space.