Thanks for your excellent idea and code, these really enlighten me a lot. There some parts of the code I don’t understand, could you please give me some guidance?

https://github.com/yinboc/liif/blob/f80be3e4fd5f1fcfbf9bbc584184e4b034e88874/models/liif.py#L82 rel_coord = coord - q_coord rel_coord[:, :, 0] *= feat.shape[-2] rel_coord[:, :, 1] *= feat.shape[-1]

What is the 'rel_coord' refer to? I think the 'coord' and 'q_coord' refer to the xq and v*t in Eq(4) in your paper, what is the 'rel_coord' refer to? I have the same problem with 'rel_cell'. Looking forward for your response, thank you!

I use the same 32x32 LR image in your paper and then run quick start to get 20x SR image, but it looks quite blurred TAT. Here is my result:

*running command: python demo.py --input input.png --model rdn-liif.pth --resolution 640,640 --output output.png --gpu 2

https://github.com/yinboc/liif/blob/68d6164f9c200e44861bb74ad489c60bbff77fbb/models/liif.py#L82 Hi, to my understanding, rel_coord here should be normalized (i.e. in range [-1,1]). Why do you multiply it with feature size? Thx!

Hi there, I've been using LIIF on emoji glyphs and got some great results, however I'd like to recover the transparency, which I had to remove* by simple alpha compositing (i.e. flattening the image) before passing the PNG inputs to LIIF.

* flattening onto a grayscale background after calculating the grayscale tone not present in any semitransparent pixels, with greatest Euclidean distance from the median of the pixel mean in the image

I tried to "supervise" the estimation of transparency but it was only a rough estimate, and the results it gives are not satisfactory (despite the high quality obtained from LIIF)

This subsection of an emoji glyph was flattened against a black background then run through LIIF. The bottom right plot shows the recovered transparency (RGBA image) flattened against a different background colour (white)

I was wondering if you think the code could be modified in some way for this, to supervise an estimate of the alpha channel?

It seems like it should be possible but it's unclear to me how I might implement it, any advice would be appreciated

when I "python test.py --config ./configs/test/test-set5-2.yaml --model edsr-baseline-liif.pth --gpu 0" it errors that—— stack expects each tensor to be equal size, but got [3, 256, 256] at entry 0 and [3, 144, 144] at entry 1

it means all image should have same shape?

Hi! I try to test the make_coord() in utils.py

def make_coord(shape, ranges=None, flatten=True): """ Make coordinates at grid centers. """ coord_seqs = [] for i, n in enumerate(shape): if ranges is None: v0, v1 = -1, 1 else: v0, v1 = ranges[i] r = (v1 - v0) / (2 * n) seq = v0 + r + (2 * r) * torch.arange(n) coord_seqs.append(seq) ret = torch.stack(torch.meshgrid(*coord_seqs), dim=-1) if flatten: ret = ret.view(-1, ret.shape[-1]) return ret

test is 0.5 * torch.arange(8),get

tensor([0, 0, 0, 0, 0, 0, 0, 0])

what is wrong?

Hi, very cool work! In your paper you write that you train for 200 epochs, but in the config files (included in this repo) you have 1000 epochs. Should there be a big difference between the two options? In terms of runtime it matters a lot... 25 vs 5 hours training time. I wonder if the final quality also changes. Thanks!

Hi Yinbo, Thank you for your impressive work. I'm confused about the coordinate conversion in https://github.com/yinboc/liif/blob/main/models/liif.py#L81 when you use them for the feature grid-sampling. The coord here denotes the normalized index of the hr images. And the q_coord seems to be the interpolated real HR index on basis of the real feature map index. I guess these are for the assumption that the pixel locates on the grid center. The following line is "rel_coord = coord -q_coord". What's the meaning of this rel_coord? I couldn't understand these conversions. And Later you multiply the rel_coord with the feature map scale for prediction. Is the range of the rel_coord not [-1,1]? Hope for your reply and thank you for your attention again.

https://github.com/yinboc/liif/blob/7f0ec6b1e0cac4b52858f1fa4a67d527fd47079a/test.py#L16 Hi, I don't quite understand the meaning of 'bsize', can you give me some guidance?

Looking forward to your response, thank you!

Traceback (most recent call last):
  File "demo.py", line 26, in <module>
    model = models.make(torch.load(args.model)['model'], load_sd=True).cuda()
  File "/lib/python3.6/site-packages/torch/serialization.py", line 426, in load
    return _load(f, map_location, pickle_module, **pickle_load_args)
  File "lib/python3.6/site-packages/torch/serialization.py", line 599, in _load
    raise RuntimeError("{} is a zip archive (did you mean to use torch.jit.load()?)".format(f.name))
RuntimeError:rdn-liif.pth is a zip archive (did you mean to use torch.jit.load()?)

Hi, thanks for the great work!

I am just curious that, is there any specific or special reason for using L1 loss instead of L2 loss during training? Because I feel like L2 loss matches better with the PSNR metric?

Thanks!

"rel_cell = cell.clone() rel_cell[:, :, 0] *= feat.shape[-2] rel_cell[:, :, 1] *= feat.shape[-1]"

What does the code mean? Before that, rel_cell stores the proportion of 2 to crop_hr.shape. So, its multiplication resultant means what?

Hi, I have a small question about the Table2 in your paper, where you only tested x6 and x8 as out-of-distribution settings. I wonder if any scale larger than x8 is possible?

My GPU memory is 32g, and the image is 3456 x 4608, now I want to resize to 6912 x 9216 by liif, but get a error hint 'cuda out of memory'. So I reduce the bsize gradually to 1, but still have the problem 'cuda out of memory'?

Hello yinbo, I have a question about the meaning of data_norm in train configuration file.I guess inp,gt mean input,ground-truth respectively.But what is the meaning of sub:[0.5] and div:[0.5]? data_norm: inp: {sub: [0.5], div: [0.5]} gt: {sub: [0.5], div: [0.5]} Could you help me?Thank you!

Hi,

Thank you for your nice work! When I was going through the code, I was a bit confused by this line: https://github.com/yinboc/liif/blob/main/models/liif.py#L105 .

From the paper I understand that the weight used is the diagnoal area when local ensemble is enabled, but when local ensemble is disabled, the weight used is the current area. I wonder whether this is bug or feature :)

Thanks.