Image artefact and method comparisons

[TJCoding]

The images used here are not fully fit for purpose.

Image 3 shows clear signs of jpeg artefact, most clearly seen from the ‘blocking’ in pic_1_2_ps.jpg.

For image 1, there is some weird ‘bubble effect’ along the horizon, which is probably jpeg artefact.

Image 2 is OK but the source image and target image look too vivid and unnatural as if they have been pre-Photoshopped.

I see that in the code, if I change
_if(makeCT(images[imgpack])) to _if(makeCTCIE(images[imgpack])) then the program runs under ‘CIELab’ rather than ‘L-alpha-beta’ and the jpeg artefact then looks fairly horrendous.

I realise that some of the images are legacy images but it raises a question. Does it matter that L-alpha-beta is so much better than CIELab on these images? Or should one make the decision on better quality images?

It is good that the code can run on both L-alpha-beta and CIELab but that should be made more explicit so that people can compare the alternatives. It might be useful also to see if there is an image pair where CIELab is better than L-alpha-beta.

[ZZPot]

Lab != L-alpha-beta That's the main point of that method. At the time when I write this code there was no built-in RGB->L-alpha-beta conversion. Artefacts - yep, this is the part that isn't covered anywhere (at least I didn't find it).

[TJCoding]

Hi ZZPot,

I am giving a response to both your emails here.

Thank you for your emails.

I have 'Close Issue' buttons available. Do you wish me to click one or the other or both? (Please be clear which you want closed).

There is something to be said for leaving open *'*Here’s what I had to do to get this code to run.' Because it might help other users.

In case you didn't realise I am assuming that the 'blocking' is due to jpeg artefact because of the way jpeg works For the encoding process, DFTs are performed on small image blocks and it is probably those blocks which are visible here.

I have implemented an advanced form of 'Reinhard' (better algorithm) but I have used Lab rather than L-alpha-beta. https://github.com/TJCoding/Enhanced-Image-Colour-Transfer It looks like I need to go to L-alpha-beta so that I can compare my processing to the photoshop images on your site. When I do this I would like to use your coding for the L-alpha-beta transforms. I hope you are happy with this I will give you full credit.

I realise that you have wound down your GitHub activities in the last year, so thank you so much for taking the time to respond to me. Thank you too for your code.

Best Regards

Keep Safe!

Terry Johnson

terence.johnson@gmail.com

On Tue, 24 Mar 2020 at 07:55, ZZPot notifications@github.com wrote:

Lab != L-alpha-beta That's the main point of that method. At the time when I write this code there was no built-in RGB->L-alpha-beta conversion. Artefacts - yep, this is the part that isn't covered anywhere (at least I didn't find it).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ZZPot/Color-transfer/issues/5#issuecomment-603084640, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO3CSO7L2D2IKYLQXE5XTFLRJBROZANCNFSM4LROF7QQ .

[TJCoding]

This Issue has now been covered by providing an additional implementation here. https://github.com/TJCoding/Enhanced-Image-Colour-Transfer This allows processing in the L-alpha-beta colour space in addition to the original processing in the CIELab colour space. The issue of image artefact and quality has been recorded in the associatede documentation.