Yeah, it's a bit odd, as my comment was on page 2 when I posted it, but when I came back to check later after seeing you'd posted again, it was on page 3, and suddenly there was an extra new comment from Medio! Mysteries of the Forum...
It's not so much a mystery, rather than the designers of vanilla thinking it was a good idea to update the page client-side when you post instead of forcing a reload (And this is not something I can easily change)
Basically, what happened is as follows.
You and Medio both clicked into the thread to read it.
While you were reading the thread, Medio posted a reply. This wasn't visible to you since you were already in the thread (not really a difference from about every other forum at this point)
You posted your reply. It was done after Medio's, but since you haven't reloaded the page, you still don't see his reply. Your text was sent to the server and inserted into the database, but instead of the page being reloaded, your view of the page was also updated clientside with your text inserted into it without reloading the page. Since the page still wasn't reloaded, Medio's reply would still not be visible for you.
Anyone accessing the page after you posted your reply would see both yours and Medios normally. Since Medio's post was the last one on page two, yours now show up on page 3 as expected.
Not reloading the page gives a smoother experience, but not one I think is favorable the way it is implemented. Maybe I'll find a way to change this behavior one day without breaking everything.
A alternative explanation is that you simply didn't notice there was more pages. Opening a thread shows you the latest unread message, which would have been Medio's on the bottom of page 2. If you didn't notice the page counter wasn't on the last page, you may simply not have realized there were further messages there.
Looks like Wyvern dropped off the end of the page. I remember there was a time gap there of about 2 hours between Wyvern's comment and my comment to Medio.
Ok. I now have holes in the roof on both tiled and thatch houses. The thatch house holes were a lot harder to work out than the tiled ones. No sharp edges!
Anyway! I was hoping to find out what you think of the 'derelict' version of this cottage. Does it go far enough... too far?
There will be full ruins in part 2 later on in December.
Over on the FB page one of the mappers inferred that there might be an issue with the black outline we use to tidy up the side effects of using a map file for the roof pitch and direction (that pink and blue image that goes with the graphic to make the house symbol). I experimented with the graphic to see if I could make the edge a bit more natural without showing the map file artefacts.
might be an issue with the black outline we use to tidy up the side effects of using a map file for the roof pitch and direction (that pink and blue image that goes with the graphic to make the house symbol)
Which side effects?
Unrelatedly, is the roof hole a separate symbol or is it baked into the basic symbols? Is it a dormer replacement?
The cross-hatched decoration (don't know what the proper term for it is, sorry!) seems undamaged despite the roof holes beneath it. As this seems to be of fairly flimsy outer surface material (compared with the depth of roof thatching), it seems unlikely it would have survived intact when the entire thatch below it has rotted away - even if it had just broken and raggedly partly fallen-in, say. I'd guess in some cases it might partly survive sort-of intact, but not always.
It does also look a little odd that none of the holes are where the greenery is; the extra weight and implication that that's where water's collecting, so mulching the thatch down into a growing medium plants can root into, might suggest that kind of area would be ripe for collapse as well.
@jslayton - If there are any semi-transparent pixels around the edge of the graphic, they show up as opaque white. I can fix this by ensuring there are no semitransparent pixels at all - at least in the VH version of the file. Here is a snapshot of the perfectly sharp VH symbol and then the lower res shot of the same, showing the white pixels that appear when the edge has been antialiased in the HI res version of the symbol.
Not everyone takes care to fix the resolution at VH just prior to export, so to counteract the unsightly white fringe we put a dark line around everything and cut the map file short of the edge by the width of the dark line.
(Having said that, of course, I've just shown you the experimental house symbols where I've taken out the dark line and replaced it with a more subtle dark inner glow on the symbol itself. It appears that the dark line can be done away with, as long as you make sure the edges are never paler than the interior).
The hole is part of the symbol, but could be made as a separate symbol as well if I have time. The handover for this set is in 7 days time.
EDIT: I've discovered that if I do the HI and LO resolutions by hand in GIMP without any antialiasing (taking the sizes from the previously created HI and LO res versions from CC3), I can also prevent the white fringe on those two resolutions. Here I have done it to the house on the left, but not the one on the right.
Thanks for the insight, Wyvern. I will think about that tonight.
Interesting that both you and Jim see A as the better symbol of the two. That one has the traditional thick black line around everything. It is the B symbol that has something more subtle.
if I do the HI and LO resolutions by hand in GIMP without any antialiasing (taking the sizes from the previously created HI and LO res versions from CC3), I can also prevent the white fringe on those two resolutions
If I understand correctly, that's a white fringe being generated around the lower-resolution images during symbol import? If so, that means it's a filtering problem in how the input images (VH) are being converted to lower resolutions. Try the SYMPTFILTER command with a value of 1 to see if it helps (if it's already 1, try 0).
Excellent! It works. Thanks Joe. I just wish I'd known about that years ago.
I had started to import the symbols, then open the results in GIMP to select alpha and sharpen the mask, fill with black on a new layer, then invert the mask and trim the semi-transparent pixels away before merging the two layers to form one antialiased image with nice clean edges. It takes too long, though, when you are still drawing new symbols on a time limit.
The symbols generated without any kind of antialiasing look rougher at lower resolutions, but at least they don't have those white fringes on them anymore, and I don't have to waste so much time preparing them all by hand now.
SYMPTFILTER dates back to September 2018, so it's a fairly new command. Unfortunately, there isn't a way to force the command line for the symbol conversion like there is for exports, so a dynamic patch isn't possible. I'll put that on the wish list.
Fringes like that are usually caused by improper use of premultiplied alpha is why I was asking. The white fringes suggest that the areas outside of your interesting RGB parts that should be RGBA(0,0,0,0) are instead being RGBA(255,255,255,0). According to imagemagick - Method for converting PNGs to premultiplied alpha - Stack Overflow, the ImageMagick command line
Again, another great suggestion. I dont' have any control over what colour the transparent pixels are if they aren't transparent anymore, but since viewing them in File Explorer occaisionaly shows them with black backgrounds I think they start out the right way - the originals I create, I mean.
Comments
No, no Sue; it's entirely down to the trees looking too good 😉
Might want some floating murky bits on the water surface now though, flotsam, etc...
Thank you, Medio :)
@Wyvern Sorry! Your comment wasn't visible when I responded to Medio.
LOL! I don't believe you! (maybe more because they will have to stay 'done' for now). I will do more trees for part 2 ;)
Water bits and debris will be later - when I've done all the buildings.
Yeah, it's a bit odd, as my comment was on page 2 when I posted it, but when I came back to check later after seeing you'd posted again, it was on page 3, and suddenly there was an extra new comment from Medio! Mysteries of the Forum...
It's not so much a mystery, rather than the designers of vanilla thinking it was a good idea to update the page client-side when you post instead of forcing a reload (And this is not something I can easily change)
Basically, what happened is as follows.
Not reloading the page gives a smoother experience, but not one I think is favorable the way it is implemented. Maybe I'll find a way to change this behavior one day without breaking everything.
Ah, you take all the magic out of it Monsen 😁😉
Then I must have opened the thread and seen Medio's reply before Wyvern finished his?
Yes, that's the most likely explanation.
A alternative explanation is that you simply didn't notice there was more pages. Opening a thread shows you the latest unread message, which would have been Medio's on the bottom of page 2. If you didn't notice the page counter wasn't on the last page, you may simply not have realized there were further messages there.
Looks like Wyvern dropped off the end of the page. I remember there was a time gap there of about 2 hours between Wyvern's comment and my comment to Medio.
Looks like Wyvern dropped off the end of the page.
Just as well Wyverns can fly 😎🐲
I love the look of the water, Sue! So different from any of the other styles
Thanks Autumn :)
Ok. I now have holes in the roof on both tiled and thatch houses. The thatch house holes were a lot harder to work out than the tiled ones. No sharp edges!
Anyway! I was hoping to find out what you think of the 'derelict' version of this cottage. Does it go far enough... too far?
There will be full ruins in part 2 later on in December.
Over on the FB page one of the mappers inferred that there might be an issue with the black outline we use to tidy up the side effects of using a map file for the roof pitch and direction (that pink and blue image that goes with the graphic to make the house symbol). I experimented with the graphic to see if I could make the edge a bit more natural without showing the map file artefacts.
So which looks better? A, or B?
I see the A one as a dingier ruined look than the B one. They both work for me, but others have better eyesight than I do.
Thanks Jim :)
might be an issue with the black outline we use to tidy up the side effects of using a map file for the roof pitch and direction (that pink and blue image that goes with the graphic to make the house symbol)
Which side effects?
Unrelatedly, is the roof hole a separate symbol or is it baked into the basic symbols? Is it a dormer replacement?
"A" looks more natural to me too, Sue.
The cross-hatched decoration (don't know what the proper term for it is, sorry!) seems undamaged despite the roof holes beneath it. As this seems to be of fairly flimsy outer surface material (compared with the depth of roof thatching), it seems unlikely it would have survived intact when the entire thatch below it has rotted away - even if it had just broken and raggedly partly fallen-in, say. I'd guess in some cases it might partly survive sort-of intact, but not always.
It does also look a little odd that none of the holes are where the greenery is; the extra weight and implication that that's where water's collecting, so mulching the thatch down into a growing medium plants can root into, might suggest that kind of area would be ripe for collapse as well.
@jslayton - If there are any semi-transparent pixels around the edge of the graphic, they show up as opaque white. I can fix this by ensuring there are no semitransparent pixels at all - at least in the VH version of the file. Here is a snapshot of the perfectly sharp VH symbol and then the lower res shot of the same, showing the white pixels that appear when the edge has been antialiased in the HI res version of the symbol.
Not everyone takes care to fix the resolution at VH just prior to export, so to counteract the unsightly white fringe we put a dark line around everything and cut the map file short of the edge by the width of the dark line.
(Having said that, of course, I've just shown you the experimental house symbols where I've taken out the dark line and replaced it with a more subtle dark inner glow on the symbol itself. It appears that the dark line can be done away with, as long as you make sure the edges are never paler than the interior).
The hole is part of the symbol, but could be made as a separate symbol as well if I have time. The handover for this set is in 7 days time.
EDIT: I've discovered that if I do the HI and LO resolutions by hand in GIMP without any antialiasing (taking the sizes from the previously created HI and LO res versions from CC3), I can also prevent the white fringe on those two resolutions. Here I have done it to the house on the left, but not the one on the right.
Thanks for the insight, Wyvern. I will think about that tonight.
Interesting that both you and Jim see A as the better symbol of the two. That one has the traditional thick black line around everything. It is the B symbol that has something more subtle.
if I do the HI and LO resolutions by hand in GIMP without any antialiasing (taking the sizes from the previously created HI and LO res versions from CC3), I can also prevent the white fringe on those two resolutions
If I understand correctly, that's a white fringe being generated around the lower-resolution images during symbol import? If so, that means it's a filtering problem in how the input images (VH) are being converted to lower resolutions. Try the SYMPTFILTER command with a value of 1 to see if it helps (if it's already 1, try 0).
Will that negate the antialiasing?
I will try it on selected symbols, since I've already converted 2 by hand and they are working well.
SYMPTFILTER 1 should use no antialiasing on the downconversion, yes. The default is SYMPTFILTER 0.
Excellent! It works. Thanks Joe. I just wish I'd known about that years ago.
I had started to import the symbols, then open the results in GIMP to select alpha and sharpen the mask, fill with black on a new layer, then invert the mask and trim the semi-transparent pixels away before merging the two layers to form one antialiased image with nice clean edges. It takes too long, though, when you are still drawing new symbols on a time limit.
The symbols generated without any kind of antialiasing look rougher at lower resolutions, but at least they don't have those white fringes on them anymore, and I don't have to waste so much time preparing them all by hand now.
SYMPTFILTER dates back to September 2018, so it's a fairly new command. Unfortunately, there isn't a way to force the command line for the symbol conversion like there is for exports, so a dynamic patch isn't possible. I'll put that on the wish list.
That would be awesome. Thank you again, Joe :)
Just out of curiosity, are you outputting your VH images as images with alpha or as images with a background color that's removed?
As images with alpha.
Fringes like that are usually caused by improper use of premultiplied alpha is why I was asking. The white fringes suggest that the areas outside of your interesting RGB parts that should be RGBA(0,0,0,0) are instead being RGBA(255,255,255,0). According to imagemagick - Method for converting PNGs to premultiplied alpha - Stack Overflow, the ImageMagick command line
should convert the non-premultiplied version to premultiplied. I should probably get something like that into the symbol importer.
Again, another great suggestion. I dont' have any control over what colour the transparent pixels are if they aren't transparent anymore, but since viewing them in File Explorer occaisionaly shows them with black backgrounds I think they start out the right way - the originals I create, I mean.