Jump to content
IGNORED

Images generated by RastaConverter


Philsan

Recommended Posts

33 minutes ago, Faicuai said:

Mhmmm...

 

Saw your image and it kind of looked odd (to me)....

 

So decided to run .exe image on actual 800 +  color-calibrated NTSC Analog-to-Digital video path (800->DVDO iScan->Viewsonic VP930b) and this is what I got (photo from iPhone, real image is much warmer and top blue band is much paler, in reality):

 

 

208698A3-9C29-47B4-9677-577B87C5FC6E.jpeg

 

 

In actual image/ screen, all browns appear much more brownish, and yellows much more yellowish.... but there is NOTHING red, of any kind.

 

This is, again, a full NTSC frame from actual 800 hardware.

I can tell you that the real color on my monitor looks just about like what you have there, and nothing like my phone-camera photo, I said it before that my camera butchers my monitor true color and saturation. I just need to find a better camera, though I did manage some descent photos of R)ger's RGBY 8x11F images in the A8 graphic capabilities thread, but they still were over saturated and the hue was off.

  • Like 3
Link to comment
Share on other sites

1 hour ago, Gunstar said:

I can tell you that the real color on my monitor looks just about like what you have there, and nothing like my phone-camera photo, I said it before that my camera butchers my monitor true color and saturation. I just need to find a better camera, though I did manage some descent photos of R)ger's RGBY 8x11F images in the A8 graphic capabilities thread, but they still were over saturated and the hue was off.

Oh!!!

 

Did not capture / read that it was your camera the one introducing such massive deviations from on-screen rendition... I hear you, I know exactly what you mean (same struggle here, at times...)

 

It's all good then!

 

Cheers and keep them coming!!!

Link to comment
Share on other sites

On 6/20/2019 at 3:40 PM, _The Doctor__ said:

nice site, you can set the number of colors you want or limit how many and sort through the pixel art.

 

On 7/15/2019 at 1:34 AM, Stephen said:

Because people love the C64 conversions :)

output.png.3a5cf49e522061cbd4a5e2dce531a9ab.png

Stephen_FlatCountry_C64.xex 22.26 kB · 36 downloads

 

On 7/15/2019 at 2:30 PM, CharlieChaplin said:

It's C64, there is not enough violet, lilac, purple, lavender... ;-)

 

 

 

On 7/20/2019 at 4:39 PM, Gunstar said:

I don't mind converted C64 images if they are done by someone else and I like the subject matter, or it's show's good artist's skills within the limitations of the graphics. But I don't want to do them anymore myself, and I would rather spend my very long time, converting images to be of subject matter that takes more advantage of Rasta's color and resolution abilities. I downloaded this one as I happen to think it's really good pixel art, regardless of the subject matter and color limitations. And of course you did a superb conversion job!

 

Back in the day, when all I had was 4-5 color, single Antic mode graphics paint programs, with no DLI option, before I got RamBrandt Art studio and Technicolor dream and later mixed-mode image viewers, I was impressed and jealous of C64 16 color graphic art, like this, when I could still only use 4-5 colors on screen. 

 

There was a time when I was NOT impressed, but disappointed with the 128 color palette of the Atari, like it was mostly useless for me as an artist since I was limited to 4-5 at a time, I didn't care how many I could choose from.  I  felt suckered by "false advertizing" by Atari of the 128/256 color Atari palette, when I could still only use 4 colors at a time in 160x192 resolution, and the low-res GTIA modes that reminded me of low-res 2600 graphics. When I saw 160x200 16 color C64 graphics (but I didn't know of the C64's smaller palette at the time) until I saw what the power of the A8 could do with the GTIA modes and how much more impressive they could be, with the extra memory and processing power, and mode-mixing, than similar low-res 128 color palette graphics of the 2600. And the ability to use DLI's and mix graphic modes as well as colors by using them, I've continued to be impressed by something new all these years later. And have long since come to realize that Jay Miners 8-bit really was/is an Amiga Jr. like what's his name of Dropzone fame commented.

 

But not afterwards, and especially for what I could do once I got Rambrandt with it's DLI options, as an artist with careful planning of color usage and DLI's, I could make a much more impressive picture *technically-if-not-artistically* with far more on-screen colors, and not just a bunch of rainbow-banding graphics like Alternate Reality The City graphic art. But if it's a well done piece of art, I like it, 16 colors or B/W, or whatever.
 

Off Topic but Albert or/and other monitors see, please try to figure out and resolvre this:

It has a post (maybe the latest on 20th July) but then it has two post from (15th) and restarts for right (Saturday 20th of July, maybe the first from that day).

Link to comment
Share on other sites

11 hours ago, Gunstar said:

mistaken quote, ignore

@FaicuaiI've figured out the issue with my color, especially in a photo on a bad camera, that I found out I have to turn the color level on my monitor down to 25, to get the camera to take a photo with color saturation similar to what it looks like on my screen at 50. But then the colors the camera recreates are not the natural ones. But the real issue here comparing yours to mine, is that you are looking at an NTSC Rastaconversion on NTSC hardware. I'm looking (and photgraphing) NTSC Rastaconversion on PAL hardware. My color's off way to the red spectrum compared to yours (with my 1200XL chroma upgrade that gives my PAL Atari's palette true reds instead of browns), but the red still looks brown to me in real life in this image, just leaning to red instead of more green in it like your NTSC screenshot. It just happens that I didn't realize the obvious, because it still looks GOOD on my PAL screen in real life, but I definitely notice color differences, like the foliage in the foreground of the image on yours is mostly green, while a good portion of it on my PAL screen is brown, I thought it was supposed to be dirt in a garden, and not the garden covered in green like yours! Most NTSC images when viewed on PAL (and vice versa) look way off and it is instantly noticeable that the colors are not right. Not so much with this picture.

Edited by Gunstar
Link to comment
Share on other sites

Another image where the .png image here looks like just shades of yellow in the trees and around the sun, but at least on my computer and screen, there are a lot of oranges and browns that you don't see in the posted image. These also don't show up at all in Rastaconverter in destination or output images. That's why I always check every attempt I do, that's good enough to save and compare with future attempts, on a real Atari. It always looks different on the real hardware. I don't use Altirra for viewing, so I can only assume when viewed in the emulator, the colors are the same as the output of Rastaconverter and the .png images.

Edited by Gunstar
Link to comment
Share on other sites

What me really bothers is the error I noticed on the real screen shot of the "park"-image:

arghh.png.3ef99d79406a59030d397476c88b900d.png

 

The former attached "output.png" (and so the "status" RC "thinks" it represents) hasn't this error.

I know RastaConverter is not perfect (and AFAIK this kind of problem is known), but since fixing such image isn't easy (RC2MCH's output for G2F isn't giving the same image for editing) this problem is really annoying (esp. after a long solving time) ...

 

However, with an other result the tool made an amend:

 

output.png.52b1975e9779bd8c5cf83668cde47b7a.png

 

(I know @Sheddy already converted the image here:

- but I've tried to preserve the original aspect ratio of the Amiga image and used/liked the chess dither too...)

 

KingTut.xex

 

  • Like 7
Link to comment
Share on other sites

18 hours ago, Irgendwer said:

What me really bothers is the error I noticed on the real screen shot of the "park"-image:

arghh.png.3ef99d79406a59030d397476c88b900d.png

 

The former attached "output.png" (and so the "status" RC "thinks" it represents) hasn't this error.

I know RastaConverter is not perfect (and AFAIK this kind of problem is known), but since fixing such image isn't easy (RC2MCH's output for G2F isn't giving the same image for editing) this problem is really annoying (esp. after a long solving time) ...

 

However, with an other result the tool made an amend:

 

output.png.52b1975e9779bd8c5cf83668cde47b7a.png

 

(I know @Sheddy already converted the image here:

- but I've tried to preserve the original aspect ratio of the Amiga image and used/liked the chess dither too...)

 

KingTut.xex 22.24 kB · 9 downloads

 

Yes, this type of error is what I personally call a "line segment error." It is documented, but not using any name that I recall, just a description of what happens. It's in the original thread of Rasta's development (under a different name, IIRC). This is what happens, as I have said many times here, if images are left to run too long. Which is why my images I almost never run more than 150 million evaluations because this error occurs MUCH more frequently the longer you run, and after 150 million the chances jump about 50 fold and up. So I redo settings and lots of attempts so the picture is "finished" before it reaches that many evaluations. and I usually will shut down the conversion process as soon as I possibly can, as long as the image looks good (judge by my results). It only shows up on the real hardware. Usually, the errors look much worse than yours does there, and not necessarily black or a dark color like in that error, just a generally stark color difference which ruins images. 

Edited by Gunstar
Link to comment
Share on other sites

Do I need to name these? Nothing special here, after attempting several versions of each, I settled on the first at default settings of Rasta. Definitely images that look better standing back from the screen.

Atari400.png

Atari800.png

1200XL.png

Atari400.xex Atari800.xex 1200XL.xex

AtariXE.png

AtariXE.xex

Edited by Gunstar
  • Like 10
Link to comment
Share on other sites

  • 3 weeks later...
58 minutes ago, Rybags said:

That earlier 400 pic is the best of the bunch, probably due to the fact that model has more colours by nature.

 

I totally agree, I was especially happy once I was able to produce an image that all the "keys" were "properly" colored. I just couldn't get the image of the 800 to have the function keys come out as good as I like. I think the 1200XL image is the second best. I'm going ahead and posting a couple images that I turned down in favor of the one I posted of the 800, with enhanced color, maybe some will prefer it. I felt the images reminded me too much of a highly discolored 800, in dire need of a retro-bright job! Of course that's when I viewed them on my real Atari with a video upgrade, it probably would look better in this case, on a stock Atari with comparatively washed-out color. The function keys came out the best on the yellow 800 version, but then they blend in to much with the yellow 800! I apparently already deleted "enhanced color" versions of the 400, but they looked like 400 versions of these 800 images.

800a.png

800b.png

800a.xex 800b.xex

  • Like 3
Link to comment
Share on other sites

On 7/23/2019 at 4:54 PM, Irgendwer said:

What me really bothers is the error I noticed on the real screen shot of the "park"-image:

arghh.png.3ef99d79406a59030d397476c88b900d.png

 

The former attached "output.png" (and so the "status" RC "thinks" it represents) hasn't this error.

I know RastaConverter is not perfect (and AFAIK this kind of problem is known), but since fixing such image isn't easy (RC2MCH's output for G2F isn't giving the same image for editing) this problem is really annoying (esp. after a long solving time) ...

 

 

 

I think I have a workable solution for the "line error" but it's dependent on the original project having been begun with /s=<solutions> parameter being set high enough to allow the rendering to repair itself.  I use a high value all the time so my repairs always work, eventually.

 

The line error occurs in two ways.  

 

An error that shows up in the OUTPUT.PNG and in the executable are a type 2 error.  If you use a reasonably high number of solutions this error type will eventually repair itself with more processing. 

 

The type 1 error only occurs in the executable.   Since it's not visible in OUTPUT.PNG then rastaconverter never knows there's something that needs fixing.

 

Here's how I fix type 1 errors.  (I wish I had taken one more screenshot but I think I can describe how the fix works without it).

 

Below is a screenshot of a conversion I've been working on for a very long time, multiple attempts and the current attempt has been running for over 2 billion evaluations.  (I don't have Gunstar's knack of getting good pictures in short rendering times.  I don't have a keen eye for color, lighting or rastaconverter's settings. Sometimes I manage to produce a presentable picture).

 

chameleon2_screenshot.png.a659f4662380b75f3545d60eb01b5d0f.png

 

Here the type 1 line error is easy to spot, quite ugly.

 

I created  a details mask and altered the files OUTPUT.PNG.RP and OUTPUT.PNG.OPT and added the parameters /details_val=2.25  (range I believe is 1-8 and /details=chameleon2_mask.png.

 

Below is the rastaconverter window just moments after I made the above change and entered, "wine rastaconverter /continue" (I'm running the Windows version of rastaconverterBeta7-icl17 under linux.  Don't ask why I'm not running a native build of rastaconverter).

 

chameleon2_with_line_error.thumb.png.20e07374e3d4463125b8cbe8a509ce9b.png

 

I don't have a screenshot of the window before making changes or one of the details mask.  Sorry.  The mask is just a simple white line drawn at the location of the line error on a black background.  You can see the mask blended with the Destination picture.  You can also see that the line error does not appear in the center picture, OUTPUT.PNG.  At the time of the above screenshot the repair to the rendering has already been completed (shown below)

 

chameleon2_repaired_screenshot.png.ee2461f9c92ea7f136b69cc334fe4d94.png

 

I was lucky.  Only a few million evaluations later the line error was gone. Sometimes the repair takes 200 million evaluations or even longer.   

Later another type 1 line error appeared at a different location.  I already repaired that one as well.   I'm still running the conversion but I hope to be posting it soon.

 

For the record I'm using solutions, /s=172000, in the above example. This is a lot. It's enough to notice a pause when rastaconverter does a save.

 

 

Edited by a8isa1
  • Like 4
Link to comment
Share on other sites

3 hours ago, a8isa1 said:

I think I have a workable solution for the "line error" but it's dependent on the original project having been begun with /s=<solutions> parameter being set high enough to allow the rendering to repair itself.  I use a high value all the time so my repairs always work, eventually.

 

 

The "line error" is a known bug existing in RC from he beginning. RC is emulating ANTIC and was created basing on awesome documentation prepared by Phaeron; during development it was tested also on his Altirra. However at the time Altirra had imperfect sprite emulation related to sprite repositioning (what is going to be drawn on the screen when you reposition a sprite to a location where "beam" is actually drawing it. Before RC, considering that there was nothing in the past needing exact behavior, no emulator had it properly implemented. After Phaeron fixed Altirra and wrote good description of what Atari is exactly doing in such situation, I planned to fix the RC too. However meanwhile Phaeron implemented to RC multi-threading and huge number of optimizations. Fixing the problem in such optimized code is not easy, as I had no time to understand exactly how the optimizations he implemented work. Phaeron can be probably the best person to fix the bug now, however none of us touched the RC code for a few years now. Other fix "by hiding the problem under carpet" could be by "rejecting solutions" during the emulation phase. Program there could check if sprite is repositioned to a position where it would trigger the bug. However also this would require better understanding of the emulation caching Phaeron did. I unfortunately work on some out-of-Atari projects and don't have time to get back to this.

As RC is random by nature if you run a few conversions of the same picture in parallel, most probably some of them won't have bugs. Also as you found out - the longer RC works, the bigger chance of the bug there is. RC works by iteratively finding better positioning of the sprites and changes of color registers. At one point to progress it needs to "reuse" the sprites. If it finds out that the best reuse is by placing it to overlapping area of previous sprite position, we have a bug.

  • Like 5
Link to comment
Share on other sites

8 hours ago, ilmenit said:

The "line error" is a known bug existing in RC from he beginning. RC is emulating ANTIC and was created basing on awesome documentation prepared by Phaeron; during development it was tested also on his Altirra. However at the time Altirra had imperfect sprite emulation related to sprite repositioning (what is going to be drawn on the screen when you reposition a sprite to a location where "beam" is actually drawing it. Before RC, considering that there was nothing in the past needing exact behavior, no emulator had it properly implemented. After Phaeron fixed Altirra and wrote good description of what Atari is exactly doing in such situation, I planned to fix the RC too. However meanwhile Phaeron implemented to RC multi-threading and huge number of optimizations. Fixing the problem in such optimized code is not easy, as I had no time to understand exactly how the optimizations he implemented work. Phaeron can be probably the best person to fix the bug now, however none of us touched the RC code for a few years now. Other fix "by hiding the problem under carpet" could be by "rejecting solutions" during the emulation phase. Program there could check if sprite is repositioned to a position where it would trigger the bug. However also this would require better understanding of the emulation caching Phaeron did. I unfortunately work on some out-of-Atari projects and don't have time to get back to this.

As RC is random by nature if you run a few conversions of the same picture in parallel, most probably some of them won't have bugs. Also as you found out - the longer RC works, the bigger chance of the bug there is. RC works by iteratively finding better positioning of the sprites and changes of color registers. At one point to progress it needs to "reuse" the sprites. If it finds out that the best reuse is by placing it to overlapping area of previous sprite position, we have a bug.

Ilmenit, thank you for the explanation and thank you for creating rastaconverter.   Picture conversions have become a hobby within a hobby.

 

Does the workaround I suggested have validity?   It seemingly has always worked when I have run into the bug but perhaps I'm fooling myself.  

Link to comment
Share on other sites

16 hours ago, a8isa1 said:

Ilmenit, thank you for the explanation and thank you for creating rastaconverter.   Picture conversions have become a hobby within a hobby.

 

Does the workaround I suggested have validity?   It seemingly has always worked when I have run into the bug but perhaps I'm fooling myself.  

Your workaround may work in some cases. With detail mask you are telling RC to "multiply distance" of pixels marked areas between destination image and the current output. By applying the detail mask you are changing what is "global optimum". Therefore RC minimizing the "global distance" (Norm. Dist.) may jump out of the previously found "local optimum" by repositioning the sprite. Unfortunately it may never "jump out", especially if "number of solutions" in LAHC algorithm (/s parameter) is small or when the newly calculated Normalized Distance is too big from the previous one.

Edited by ilmenit
  • Like 1
Link to comment
Share on other sites

On 8/11/2019 at 9:03 PM, a8isa1 said:

 

Below is a screenshot of a conversion I've been working on for a very long time, multiple attempts and the current attempt has been running for over 2 billion evaluations.  (I don't have Gunstar's knack of getting good pictures in short rendering times.  I don't have a keen eye for color, lighting or rastaconverter's settings. Sometimes I manage to produce a presentable picture).

 

 You can also see that the line error does not appear in the center picture, OUTPUT.PNG.  At the time of the above screenshot the repair to the rendering has already been completed (shown below)

 

chameleon2_repaired_screenshot.png.ee2461f9c92ea7f136b69cc334fe4d94.png

 

I was lucky.  Only a few million evaluations later the line error was gone. Sometimes the repair takes 200 million evaluations or even longer.   

Later another type 1 line error appeared at a different location.  I already repaired that one as well.   I'm still running the conversion but I hope to be posting it soon.

 

For the record I'm using solutions, /s=172000, in the above example. This is a lot. It's enough to notice a pause when rastaconverter does a save.

 

 

That's a great lizard image, by the way, any chance of an .xex soon? I know what it can be like though, when you are staring at the original and destination images and seeing something that is just not good enough in the output. I sometimes go back and look at images I did and just weren't acceptable to me, comparing to the source, and so I never posted them. Then I go back months or years later, and think they aren't so bad and I'm not sure if I remember even why I chose not to post it, not having the source to compare to anymore...

 

I've rarely been 100% happy with my image conversions, there's always something I'd like to get better. Like the image I just posted above, I'm still not happy with the sky, there's too much blue streaking for my liking, but I'm tired of working on it, and it's decent, so there it is. This one, by the way, was ~500 million evaluations compared to the usual 100-150 million. I've decided to save by 150 million, then just let it keep converting overnight and stopping in the morning, compare to first save, and maybe get lucky like this one and not get a line segment error...maybe I'll start calling them sprite errors...by the way, the 500 million and 150 million evaluation versions are pretty much just as good as each other. There are some minor differences, but there are areas where Rastaconverter did more solutions and it came out worse just as often as an improvement, as near as I can tell. So little changes above 150 million I find it a waste of time, most of the time. It's like sweeping up a pile of dirt with a broom into a dust-pan you get the vast majority, 98% on the first sweep and then the remnants on the second, and with Rasta, the first 150 million equals that first sweep, and anything after is diminishing returns into ~infinitude.

Edited by Gunstar
Link to comment
Share on other sites

21 hours ago, Gunstar said:

That's a great lizard image, by the way, any chance of an .xex soon? 

I'm not sure.  I now have a type 2 line error that's not repairing itself, even with a details mask in place.

 

I've started a PAL conversion but it is not even close to resolving.  Too bad.  I liked the destination picture even better than with my NTSC conversion.

 

I'm probably going to be spending time tweaking that PAL one.

  • Like 1
Link to comment
Share on other sites

@a8isa1  I've got to start doing more NTSC images myself. I have an NTSC 800 now, so I can check them on real hardware, but until I get around to getting my SDrive max working, that means having to make an. ATR and then a real floppy to test it on the 800 unless I move either the PC beast or the 800 beast about to use with my SIO2PC & APE. I've got the PC and 1200XL PAL in close proximity and working together, the 800 is alone in another room with two floppy drives and a The!Cart. I suppose I could figure out how to use .xex's with The!Cart, and program it with them, but that's sounds like even more a tedious process than make a floppy disk, just for images...

Edited by Gunstar
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...