Seamless Mural?

I'm trying to create a multi-prim mural from a single image. I've reduced the original to 2048px on the longest side, and used an image slicer to cut it into chunks. I imported the chunks, put them on prims, made sure prim dimensions matched the chunk dimensions, and that the prims were touching precisely. Yet I still get very visible seams between the chunks. I know it can be done seamlessly, as I've seen it on things like "holodeck" products, but I can't get it to turn out right. Any suggestions?

I think you might have better results if you upload one texture, put it on all 3 prims, and then just move the texture horizontally on each prim until you get an exact match. I have done this in the past with good results. In addition, people will only have to rez ONE texture for all 3 prims instead of 3 textures, which will help reduce rez time.

Alternatively, you could find a single megaprim in the size you need for your mural.

I had thought of the megaprim approach, but my concern was the size of the image -- I want it to be large enough to not be too pixellated at that size. My concern was that a 2048px texture would be slow to load, but now that I think about it, the combined size of the smaller images would be just as big as the full image, if not bigger. I'll give it a shot.

I think SL will convert an image larger than 1024 to 1024 at upload time. See /109/e6/150360/1.html for info on the subject of image sizes for use in SL.

I've experimented in the past, uploading the same image at 1024px and 2048px resolutions and applying them to a 10m prim. I then lined up the two prims front to back, zoomed in very closely on the front one, then moved it out of the way, so I had a very close view of the exact same spot on both images. There was a definite difference in image quality and pixellation.

For a short time, a couple of years ago, 2048's were allowed in SL. But it was soon discovered that certain video cards would crash upon trying to load them, so the limit was quickly lowered back to 1024. All 2048's already in-world at that time were downsized to 1024. And both before and since then, nothing larger than 1024 has been allowed. If you try to upload a 2048, it will be downsized to 1024.

I'm not sure what you think you were seeing in your described experiment, but I wouldn't put too much stock into it. There are a million factors that can cause an apparent temporary reduction in image quality. Further, whatever image-editing program you used to do the downsizing might have been using a less than ideal interpolation method. Photoshop currently has five different interpolation schemes to choose from for image scaling, and in programs that don't allow you to choose, it's just luck of the draw. Some are better for certain types of images than others, and some are just not very good at all. SL's is well in the middle. It's not as bad as some, but it's also nowhere near as good as PS can be when you use the right settings.

For best results, always size your images properly before upload.

Siann

Can you post a picture of what you mean?

Are the visible seams part of the texture or is this the flashing often seen when 2 prims are not actually aligned although you have matched them perfectly as you say and think.

If you want to know if your prims are perfectly aligned then send me a copy of just the linked prims (no textures) and I will tell you if they are perfectly aligned or not with a follow up post.

If it is your texture do you have the repeats set at 1.000 for both Horizontal and Vertical repeats?
If so then trying to increase the size by lowering the repeats will most probably mean it is no longer seamless depending on the level of detail.

Try slicing the image slightly larger than intended and use the repeats and offsets to align it in SL.

I think I know the problem.

SL tries to tile all textures, even if you have a 1.000 repeat in both X and Y. I had a similar problem when making a football field using 1024 x 1024 textures spread across blocks of 9 prims each. There were 8 of these textures used, to make the full-sized football field (Which is in the RUCE 3 sim, if you want to look at it.) All 8 textures were made by slicing apart a very huge 2048 x 4096 pixel texture.

Within each 3 x 3 block, there were no seams. The single texture tiled seamlessly across the prims.

At the edges where two texture blocks met, there was sometimes a visible glitch. What was happening was I was seeing a one-pixel line from the far edge of the texture, as SL attempted to "tile" my texture.

===

One way to fix this, in your case, is to go ahead and slice your mural into 1024 x 1024 sections, or even into 512 x 512 sections, and place the pieces one texture per prim. BUT, don't set the repeats to 1.000 X and 1.000 Y. Instead, set them to 0.990 X and 0.990 Y, which will strip off that one-pixel bleed from the far edge. While you technically get a slight loss of data at each edge, the match edge to edge will be almost imperceptable.

I had the exact same problem when I recently designed a number of textures for a qtr sim project I was doing with, grass, pathways and shadows etc.

When I applied the texture (I was texturing 32x32 megas as well not that it makes a difference) I could not on one or 2 of the textures get rid of the very faint overlap/line that could be seen when I zoomed out. Close up it was not really there but when I tried to tweek it using the repeats and offset the seams just got worse.

In the end I actually uploaded the same image slightly larger therefore in theory it would be overlapping but with the repeats and offset I was able to align it seamlessly.

I have never seen this before and I just finished another project with 32x32 megas for a snow/winter scene with pathways etc, I had no problem with the textures there but since the previous one we have had a Viewer Upgrade so I am not sure if thats was a problem with that viewer.

I know how to properly construct an experiment and eliminate variables. I know what I saw, and that's exactly what I reported: uploading a 2048px image produces a better result than a 1024px image (I neglected to add that I located the images in my cache, and the 2048 was larger. I should re-do the experiment and see how the file sizes compare to the originals). Now, it may very well be a matter of SL using a better compression algorithm than what I am (PSP 7), which is great -- it means I can upload originals as large as I want, without worries. In fact I uploaded a 2048px version of the image I'm trying to make a mural of, and stuck it on a 32m megaprim, and it looks great. Perhaps I'll try the 3000px original and see how it looks.

(Interesting note: when PSP was on version 6, I had the opportunity to compare its image compression to the then-current version of PS. PSP was far superior.)

Sure: http://flickr.com/photos/siannbeck/3114020668/ (View the large size)


Sure, I can send you the mural object. I'll need to re-construct it on the main grid, unless I can send it to you on the beta grid. I checked the alignment manually, though, down to five decimal places. If you know how to get it better than that, I'm always willing to learn!


I did (and that's how they're set in the shot above), but tried 0.998, based on Ceera's suggestion, and that got rid of the seams. Of course, there's a slight image misalignment then, but not nearly as noticeable as the seams. However...


Not a bad idea -- make the cuts a pixel larger, and then adjust the offset to compensate. I won't have the time to try it for a day or two, but I'll post the results here.

Not sure how your getting/able to view 5 decimal places but the maximum is actually 7 and does not require a script to view just the normal edit menu and some eidting of specific files that are on your computer.
There is no need to send me a prim copy inworld as it is clearly not the prims it is the texture itself.
Using Ceera's method won't work as you have discovered hence my previous post posting re a similar problem.If I am making textures that do not need to be tileable and on a large scale I tend to go with the slightly larger image and adjust it using the repeats and offsets. Its much quicker and less of a problem.
The problem you are having is something different to what Ceera and I both experienced, the one thing I did not mention is that when I actually tiled my texture in question it was seamless but when applied to a mega prim it was almost as if the repeats were 1.001 with the opposite side just showing.
Your problem however is one that has been mentioned just today in this post
/109/f9/297875/1.html
See post 11 and thereafter and has been discussed in other threads in the past.

That may be, but the method you described, simply looking at both images from a fixed distance one time, is not it. I get the sense you're somehow offended by what I said. Forgive me if I'm misinterpreting, but your wording seems a little defensive now. You shouldn't be offended. I'm simply explaining how these things work. That's not a criticism of you in any way.


What you actually saw with your eyes is not in dispute. The conclusions you drew from your observations, however, might not be factually accurate, no matter how logically correct they may have seemed at the time. It's easy for observed results to be misleading with these kinds of things. That's all I was trying to say.

Again, that's not a criticism of you, your visual acuity, or your reasoning skills, in any way. Sometimes what seems logical and obvious is not actually correct. To really know what's happening, you have to do some digging under the hood.

One thing you left out of your report was WHEN you conducted your experiment. You said it was a while ago. It's possible it was during the time period when 2048 was allowed.

But whether it was or it wasn't, there are about a million reasons one texture might appear more pixelated than another at any given time in SL. Their actual appearances might have nothing to do with it. A great many chaotic factors could have affected your observation at the moment you conduct the experiment.

For an extreme example of why mere visual observation isn't always reliable, I'm sure you've seen a texture all of a sudden blur before in SL. It happens all the time. For seemingly inexplicable reasons, what was crystal clear one moment can temporarily become a total mess the next.

One potential flaw I notice in your described experiment is that you looked at the textures immediately after uploading them. While this isn't always a problem, it sometimes CAN be. When SL uploads an image, it creates four different versions, at progressive levels of detail. Ordinarily, all four levels are created in just a few seconds, but sometimes it takes far longer. It's not uncommon for a newly uploaded texture to get "stuck" at the third level, the fourth one then not appearing until as much as 24 hours later.

I'd be curious to know how both textures look the next day, the next week, etc. If they stay the same, then your initial conclusion was most likely right. But it's entirely possible things could change, as the detail levels finalize over time.

That's one possible explanation, out of many, for why your one-time experiment might not have yielded accurate results.


By all means, repeat the experiment. But be aware that merely comparing the file sizes with the originals won't be very telling. SL converts all images to JPEG2000, a highly compressed format, at the time of upload. What might be megabytes worth of difference in the uncompressed source images could be extremely negligible in the resulting JPEG2000's, depending on the content of the imagery.



That's certainly a possibility. PSP 7 is nine years out of date at this point. If nothing else comes of this discussion, for Pete's sake upgrade already! An upgrade to the latest version would only set you back $49.99, so you know.



Not necessarily. 2048 to 1024 is an easy conversion. Halving is always the simplest thing for any downsampling process to do, especially when all the numbers are powers of two. Less neat and even divisions may yield drastically different results. Going from something like 2500 or 3000 down to 1024 won't look as good as going from 2048. Depending on how picky you are, the differences may or may not be noticeable to you, but they will be there.



My guess is the 3000 will look worse than the 2048, but again, whether or not you might think so will depend on how picky you are, and how well-trained your eye is to notice certain artifacts.


Compression and down-sample interpolation are two different things, so I'm not sure how that's relevant. That said, are you sure both programs were using the same compression scheme, at the same settings? PS has always allowed far more user-control over just about all types of settings than PSP has, which means there's a lot more opportunity for human error.

It's kind of like comparing the difference between how a family sedan handles with how a race car handles. It's not quite a fair comparison, unless the driver has equal experience with both.

If someone's used to driving an Accord, and then you throw them behind the wheel of a Formula One car for the first time, they're undoubtedly going to tell you the sedan handles better. But that's only because they haven't yet learned how to make the race car do everything it's capable of doing.

Both cars are equally capable of providing a simple ride around the block, but if the driver has no experience with a race car, he's likely to take out a mailbox or two along the way. Would he then be justified in saying the race car handles worse than the sedan? If that's the only experiment ever conducted, the logical answer could very well appear to be yes. But that doesn't mean it's actually true. Certainly, an Accord would never be able to execute a hair-pin turn at 150mph like the Formula One car could. If one knows how to use a race car, it's a far superior vehicle to a sedan, but if one doesn't, it's likely to appear just an overly complicated monstrosity that is harder to use than it "should" be.

By the same token, if someone's used to using a relatively un-open-ended (if that's a phrase) program like PSP, and then sits down with Photoshop for just a few minutes, it can be easy to make the snap judgment that PSP is "better" at doing certain things. But again, that's only because the user hasn't yet learned how to make Photoshop do everything it's capable of doing. I can promise you, there is absolutely nothing PSP can do that Photoshop can't. Apply the same settings to the same task, and both programs will yield the same results. But since Photoshop is so much more open-ended, with so many more options for complete user control over so many functions, it's easily possible to get much better or much worse results for any given task. To get the best possible results, the user first needs to learn what he or she is doing.

For what it's worth, I really like PSP. For the money, it's a great program. But it's no Photoshop. PSP does what it does, and it's pretty good at doing it. But in terms of power and user options, there's really no comparison with Photoshop (which of course is why Photoshop costs 7-10 times more than PSP).

"The [person] who takes offense where none was intended is a fool."
-- Brigham Young

I'm no fool

That said, I didn't cover all the details of the experiment, but then I was just mentioning it in a more-or-less offhand way. I was pretty thorough; most of the variables you mentioned were eliminated. I'm not sure what you mean by "one time" -- that I only conducted it on one occasion, or that I simply looked at each image once, and made my judgement from that. Yes, it was only one occasion, but I went back and forth between the images several times, and in fact on more than one location on the image. I will do it again, and get some screen shots.


I don't remember when exactly I conducted the experiment, but it was early this year, so probably not in the 2048px era.


This is the one factor I didn't consider, as I was unaware of it. I of course allowed reasonable time for the images to rez before looking, but I'd say I was finished within an hour of uploading, so if there was possibly further resolution to be had later, that would have been missed.


Sure, that would be more of a curiosity factor than anything; although at the time I wrote that I had something in mind that might be gleaned from the comparison, but now cannot remember what it was.


Yeah, I know, I'm cheap And PSP7 has pretty well continued to served my needs. I have tried the X2 demo, and will probably upgrade soon.


You're right; I misspoke. I meant down-sampling. And really, I only mentioned it offhand, as it very definitely was not a rigorous comparison.

(Historical note: I used to teach Photoshop classes back when version 2.0 was hot off the press, and even met the Knoll brothers. Extra credit for anyone who can tell me what platform I used.)


Oh, certainly. No disagreement.

With a script
Do tell!

Well, not perfectly, but it did get rid of a lot of the problem. I suspect that that plus slightly overlapping the cuts will take care of it, as you say.

The issue of edge blurring when resizing? That doesn't relate here, as I don't re-size the chunks after they're cut, and the edges between the chunks is where the problem is occurring.

Very cool.


Unless I'm mistaken, 2.0 was Mac only, but I'm thinking I probably must be mistaken because that's too obvious for an "extra credit" question. I'm pretty sure 2.5 was available for Mac, Windows, IRIX, and Solaris, but I thought 2.0 was just Mac.

I was in high school at that time, though, and I didn't pay much attention to such things (or much of anything besides girls and guitars) back then, so my information could be wrong.

No without a script



Siann I can add the details here but I will not.

It requires the editing of a certain file that is installed with the Second Life Viewer.
For this reason I would not publish the details here as I would not want to be responsible for this information ending up in the wrong hands only to answer a post that someone cannot access SL anymore because they edited the wrong file or being blamed for someone elses incompetence.

When I am inworld next I'll send you a notecard.

Note, there is a fault with using this option depending on where you are building on the sim, for some reason after a certain height the Z-co-ord will become a minus, the same applies to the x and y co-rd across the sim. If you input number direct when it shows as a minus your prim/build or linkset will disappear. On the z-co-ord it will remain on your land but might end up buried but on the x and y co-ord you will have to wait for it to return to lost and found.

Its best to only build on land and around the middle of the sim but all that said I have been using this method for nearly 2 years and so its something I have learnt to live with.

As this is not official I don't think raising a Jira would make any difference.

This in my experience does not just relate to the resizing it does also relate to the same method you are using, slicing.

The white line is typical of what I experienced many times in my early days designing in SL, no-one has yet to actually give a full explanation as to why this actually occurs or a suitable workaround as I think it really is down to the individual.

I am not entirely sure what options are available in PSP7 but as a CS user rather than use the slice tool, I would copy the entire image over to the smaller file, then using offset filter to break it up into its respective parts.

Another method I use is to also save the finished texture as a pattern, create a file that is 4 times larger than the original, create a layer and fill with the patern. Normally I can pickup an irregularities in the texture from there prior to my uploads to SL.

No, you're right. It was an easy extra-credit question

http://en.wikipedia.org/wiki/Adobe_Photoshop_release_history

You asked how I was able to work with five decimal places, and that was my answer.


No problem. If it's unstable, I'll probably stick with 5 decimals, but it's good to know.