Image Quality Disparity


#1

Good day all! :slight_smile: I’ve had a few users comment about the image quality in my gallery, which seems to be pretty hit or miss. Here are a couple of examples:

This image comes through crystal clear, as does most of the gallery:

However, other sections look like this:

My assumption is that these images simply aren’t being loaded at full resolution and get “stuck” at this ugly pixelated stage. Is there something I can do about it? Is it perhaps something in my client settings? Something I need to adjust in my domain settings? Any help would be ever so much appreciated.

Thanks!!! \m/(>.<)\m/
- KpR²


#2

Is this .png or .jpg?


#3

Hi @Alezia.Kurdis,

The embedded images are JPGs. I’m presuming just from your question that I should have been smarter about the format and chosen something lossless?

Thanks much!

  • Ken

#4

I’ve actually had my own avatar experience it, where the textures do not fully load all the way. This seems to be a client based issue, and if the textures are JPGs (assuming progressive is enabled), it sounds like something in Interface regarding progressive loading is partially broken.


#5

This may well be the case since they load fine at times but not others, as seen here.

I’ll try swapping a couple of the JPEGs out for PNGs and see if it gives me more consistent results.

Thanks Flame!


#6

(Noob alert! Noob giving advice!)
AFAIK progressive encoding doesn’t give any compression benefits, or even worsens compression.

If you’re worried about having empty frames while the images load, you could maybe have a something in the frame right just behind the painting that serves as a loading screen.

Noob question:
Are these baked in, web entities, or what?

Noob bonus question:
What’s the resolution of the images? I’ll visit soon and I’m curious as to what you find appropriate for a given frame size.


#7

I’m loading the gallery right now and would you believe I can see the paintings but everything else is still loading?
Yes, at least a few of them loaded BEFORE the walls that hide them from the entry point.


#8

Hi @Yossi.Spinoza.Premin :slight_smile: Thanks so much for taking a look! The files should be baked, at least as far as anything uploaded to the Asset Server is. The images themselves vary a bit but the majority should be 3300 x 4200 and 150 dpi, which is likely still more than necessary but I was trying to make sure the quality came through. Looks like I messed that up, lol! :stuck_out_tongue:


#9

Update:
STill not been able to fully load in… My ISP hates me, but not as much as they will after my next support call.

Regarding resolution, it’s probably not really useful to have images more than perhaps 1.5x or 2x of the per eye resolution of current HMDs, unless you want to show off the fine details of the canvas and have people put their nose in to see it, or if it’s a huge mural.

Then again, it’s not bad to build stuff that’s future proof.


#10

Not what i’m used t when I visit a museum… :stuck_out_tongue:


#11

ROTFL! Oh my, that is certainly minimal, hahaha! Normally I’d have flying disabled too, so you hopefully wouldn’t notice my one-sided roof, lol. I was working on adding a theater area this morning and must have forgotten to turn it back off. :stuck_out_tongue:

I considered dropping the dpi on the images to 72, as that’s all most screens will display anyway, but was trying to avoid potential pixelization problems, etc. Here I am running into them anyway, though, so maybe I should go ahead and trim whatever I can wherever I can, try a lossless image format, cross my fingers & my eyes, turn in three circles, pray to whatever gods may be, and try again :wink:

Thanks one more! I really appreciate all of your input and feedback.

Have a great day!
- Ken


#12

IDK what you mean by DPI and how that affects images in HF.

As far as I understand the DPI value of an image should not have any effect on how it’s displayed in HF.
In HF there’s the entity size (120cm x 160cm frame for ex.) and there’s the pixel width/height, you can derive DPI from that but it means very little.

I don’t think a lossless format would improve things, just make the size larger.
The problem here is file size which results in slow loading, and the progressive encoding which made the images appear in an incomplete state and results in a displeasing experience, much better the picture be missing than fugly.


#13

I’ve enjoyed the gallery. I can guarantee it’s a bandwidth issue. I’ve stood there while some of them went from unclear to clear. i would leave an unclear area to return to find they were now clear. IMHO…


#14

Thanks so much for your feedback @HapticMonkey! I’ve got a pretty fat pipe bandwidth-wise and a fairly capable PC as well, so it does make me wonder. It seems more an “order of operations” issue with the loading, and some of the images are only being loaded so far & then ignored. Bandwidth is certainly someplace to look, and very well may be the issue, but it does leave me scratching my head as I’m certain my machine & connection should fare far better than anyone on, for instance, mobile. I don’t know… sigh I’ll just have to fiddle about & try a few things it seems.

@Yossi.Spinoza.Premin: DPI means “dots per inch” or how “dense” the image is pixelwise. Most screens (& I imagine HMDs) can only show 72 dots per inch, but for printing purposes you’ll want something larger & I typically create my artwork at 300 dpi for that reason. I’ll be testing both changing the format & the resolution of the images in question to see what sorts of results I get. Having a partial understanding of the differences between lossy and lossless image compressions, I imagine that the PNG version would simply “load” all at once, and not load in stages as the compressed, lossy JPG does. I may be talking out of my butt, and that wouldn’t surprise anyone who’s met me, lol, but it makes a certain sort of sense to me at least. If I get anywhere with my experiments, I’ll be sure to follow up with the results.

Thank you all!
- Ken


#15

Uh… I didn’t say progressive loading had compression benefits at all. I was pointing out that progressive loading seemed to be having issues as of late, which at least effects KTX and, assuming the pictures were progressive JPEGS, that other formats may also be effected.

Since he mentioned they were baked, this means they’re KTX, which goes with the issues I’ve been hearing of as of late.


#16

It doesn’t work like that at all in HMDs, DPI is indeed needed for printing, but most everything else goes by pixels or by other parameters.

What matters in VR are the image width/height in pixels and the entity width/height in meters or whatever.

I could maybe explain better with a whiteboard…

Not quite. it’s not about being lossy or not, it’s about being progressive.
If a JPEG is NOT progressive it would show partway like that, despite being lossy.
OTOH a PNG can be progressive (interlaced) and it could show up partially, but I’m not sure HF would allow that. IIRC for textures interlaced PNG is verboten.

I think the best practice would be to avoid progressive encoding completely. That stuff belongs in the 90s on geocities. :stuck_out_tongue:

@FlameSoulis

Uh… I didn’t say progressive loading had compression benefits at all.

I didn’t mean to imply you did, I was just clarifying in case Ken thought they do.


#17

I coded this calculator that can give you some guide line regarding the resolution you need depending the size of the object and the minimal distance under which you allow to see a degradation:

http://metaverse.bashora.com/TextureSizeCalculator.html

This is of course approximation.


#18

You guys are an absolute wealth of information & I simply cannot thank you enough. I’ll have to do some tinkering, but I’ll certainly make use of the calculator @Alezia.Kurdis coded (awesome, thank you!!!) and will see if different image formats make a difference as well. As @FlameSoulis pointed out, this may stem from issues within the client itself, and fixing anything there is sadly still outside my bailiwick for the moment.

Rock on my friends! \m/(>.<)\m/