Some image conversions I made

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Some image conversions I made
by on (#72420)
Image

Some time ago I wrote a tool in C# to convert arbitrary images to be displayed in NES demos etc. I thought I'd share some of the images I've converted using it (most found from the interwebs). The tool isn't completely automatic, it requires preprocessing in Photoshop/some other image editor.

The above image was captured from Nestopia with NTSC filter turned on, although I had to manually blend the "interlace" frames together in Photoshop because GIF can't animate fast enough. It's pretty close anyways.

The images are "bitmapped", i.e. CHR bank is switched 3 times while rendering. Nametable is also switched every 8 scanlines for 16x8 attribute area. Sprites are overlayed on top for more detail, with varying results. Also (in some images) a different image is displayed every two frames for bigger (pseudo)resolution. Total amount of data per image is about 20KB, twice that for interlaced ones. Some of my personal favourites are "cry", "hui", "hui2", "kompovoittaja", "koopa", "luut", "testi" and "woo". "testi" is special, it has slower flicker rate to give it a 3D feel.

There are 35 images in the pack. Nestopia is preferred. Some images are NSFW. :oops:

Download: http://kkfos.aspekt.fi/downloads/bunch- ... l-1-v2.zip

EDIT: version 2 link updated

by on (#72422)
I should note that the ROMs when loaded in Nestopia with its Region option set to "Auto" (the default) do not appear to work correctly -- they appear to resort to NTSC. Forcing PAL in the emulator fixes it.

The problem is that the header on the ROMs is incorrect. Taken from angel2.nes, file offset 0:

Code:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
-------------------------------------------------------------------
4E 45 53 1A 08 08 40 00 00 00 00 00 00 00 00 00    NES...@.........
-------------------------------------------------------------------
                           ^^

Byte 9, as shown above, is zero, which means NTSC. Set this to 0x01 (bit 0 = 1) to indicate PAL. Doing so fixes the problem. File format documentation is available.

Please fix this in all of your ROMs and remake the .zip file. Thanks!

EDIT: The Famitracker playback code apparently automatically detects an NTSC or PAL console; possibly you could use the same technique to ensure that the ROMs work on both regions?

by on (#72423)
koitsu wrote:
I should note that the ROMs when loaded in Nestopia with its Region option set to "Auto" (the default) do not appear to work correctly -- they appear to resort to NTSC. Forcing PAL in the emulator fixes it.

Thanks, I didn't know Nestopia checks (and honors) that flag. Not going to update the zip right now though. :)

Quote:
EDIT: The Famitracker playback code apparently automatically detects an NTSC or PAL console; possibly you could use the same technique to ensure that the ROMs work on both regions?

Yeah I'll probably do that when I get around to polishing the code. Pornotracker iNES player does the same.

by on (#72430)
Well I see your passion for girls is still as intense. (and 60's supposedly herotic stuff isn't my thing but oh well everyone likes different things)

The quality of images is really breathtaking ! It remembers me a C64 utility that was called Project One (if I remember well....) that could convert any pic to be displed on the C64, and it was similar. I worked also wonder with hentai-ish pics, not so well with real pics.

Why are some pics flicering (well a good half of them actually) ? I prefer the still ones. Are they supposed to be interlaced ? If so it'll only work on modern displays (like mine) but then you have 1/2 chances of having lines reversed, how can you prevent that ?

Of if they aren't supposed to be interlaced, but are supposed to average the colors, then I beg you to give up this idea. Batman's intro looks horrible on all displays I tried it on (interlaced and not, emulated and not), I don't want this error to be repeated.

But yeah the quality is really awesome ! Hard to imagine you had to work with the limiations of the NES, which are complex to handle, as opposed to the limitatoins of the C64 which doesn't have this attribute table thing.

by on (#72432)
Bregalad wrote:
Well I see your passion for girls is still as intense.

Haha.. what can I say. :twisted:

Quote:
(and 60's supposedly herotic stuff isn't my thing but oh well everyone likes different things)

60's where? :)

Quote:
The quality of images is really breathtaking ! It remembers me a C64 utility that was called Project One (if I remember well....) that could convert any pic to be displed on the C64, and it was similar. I worked also wonder with hentai-ish pics, not so well with real pics.

Thanks! I also think the result are decent. I've also used Project One (trivia: it's called that because it's made in Visual Basic and the default project name is Project1 :) ).

Quote:
Why are some pics flicering (well a good half of them actually) ? I prefer the still ones. Are they supposed to be interlaced ? If so it'll only work on modern displays (like mine) but then you have 1/2 chances of having lines reversed, how can you prevent that ?

Of if they aren't supposed to be interlaced, but are supposed to average the colors, then I beg you to give up this idea. Batman's intro looks horrible on all displays I tried it on (interlaced and not, emulated and not), I don't want this error to be repeated.

Yeah it's supposed to average the colors, there's no way to combat that 50%/50% problem to display a real 256x480 interlaced image and even then, like you said, it would only work on modern displays.

I was aiming for "average the colors" with flickering (I have source images which are 512x240 or 256x480)... so it basically simulates resampling 512x240 or 256x480 image to 256x240. That's what I mean with "pseudo resolution". Personally I like the effect, but I guess it's not for everybody.

I think Batman is little bit different though, in most of these images the flicker effect is quite subtle (large pixel areas usually stay static) whereas in Batman it flickers between two completely different screens. I'm not fan of that intro either.

by on (#72434)
thefox: :D

Some of my personal favorites are kameli, kompovoittaja, luut, testi (of course), tubak, and woo. Very beautiful stuff.

Now this is all very beautiful, and I'm pretty sure you might have considered this idea, but as a challenge do you think you would be able to pull off a water ripple effect with the dithering? Maybe you can find an image of someone looking at their reflection in a puddle or something.

by on (#72436)
Well, I think one should never make something blinking if it's not supposed to flicker.

For example, if your hero is invincible after getting hit, make him flicker. If you want to add a cool effect to animated fire, make it flicker. But, by all means, if you want something to be transparent or some way to average color, DO NOT MAKE THEM FLICKER.
This is the global consensus, no matter if it's still screens or wathever. I mentionned Batman's intro, but there is also the water area in Castlevania 3, which are the same problem.
Konami throught "well we'll make Trevor's leg's flickering so that the color will average, and they'll look like they're in water". NO THEY DON'T they look like crappy filtering legs (emulator / old display) or like horizontal vermicelli (modern display with interlacing).

Also I tested them on my new monitor, and apparently it switches the even/odd interlacing every half second or so for some reason, so it looks horrible, it flickers at about 1 Hz, which is even worse.

The pics that doesn use flickering, such as Angel 2, Joku, Teen and Teen2 looks really amazing.

The individual frames in most flickering images looks really good by themselves, but you have to pause emulation to really admire the pic.

When the flickering is very slight, such as in "retarded", it might actually look decent. The worst is as seen in "cry", there is a lot of flickering full areas which looks just horrible.

Quote:
60's where?

Well some of those pics are just 60's old-fashioned (or it might be 70's, to me it's the same).

by on (#72438)
Agreed, flicker is SO annoying. (I paused it on FCEUXD. Couldn't take it.) but other then thats, it's awesome! The NESS one was terrific! :D Awesome tool and cool stuff. :D

by on (#72440)
Unfortunately, flickering doesn't work as well as we'd like. The result is too distracting and hard to look at, killing all the beauty of the images.

Still, most of these images look nice, even though flickering at 50Hz is even worse than flickering at 60Hz. The tricks with the vertical stripes are very nice, and more suited to actual games IMO.

by on (#72446)
If you're running it on an emulator on a laptop display, the flicker looks good from LCD blur. If you're running it on a NES connected to a HDTV, there is real interlacing, hopefully not inverted.

by on (#72460)
Thanks for all the comments.

B00daW wrote:
Now this is all very beautiful, and I'm pretty sure you might have considered this idea, but as a challenge do you think you would be able to pull off a water ripple effect with the dithering? Maybe you can find an image of someone looking at their reflection in a puddle or something.

Other than converting each animation frame separately (at 20KB a pop) can't really be done. Would still make a funny tech demo so I might give it a go if I find a good animation. ~10 or so frames should make a pretty good repetitive animation. :)

tokumaru wrote:
Unfortunately, flickering doesn't work as well as we'd like. The result is too distracting and hard to look at, killing all the beauty of the images.

Still, most of these images look nice, even though flickering at 50Hz is even worse than flickering at 60Hz. The tricks with the vertical stripes are very nice, and more suited to actual games IMO.

Yeah, some images work better than others, much of it is up to randomness (and tweaking the parameters). The two flicker/interlace frames are converted separately without knowledge of each other so sometimes large areas might receive completely different colors, so it doesn't always look that great.

Oh well, I was expecting that the flicker would split opinions. :)

by on (#72474)
Quote:
If you're running it on an emulator on a laptop display, the flicker looks good from LCD blur.

You probably have a quite old laptom then. Mine is a Lenovo Think Pad T400 bought in 2009, and it doesn't have any blur at all.

by on (#72475)
I only get limited LCD blur when the picture is two frames perfectly alternating at 60FPS. When you flicker Red and Blue on the screen, it looks like solid purple.

by on (#72478)
Well, I tested Rad Racer, to see what it would look like. When you turn "3D glasses mode", outside of the road the blank area flickers between solid red and solid green, so that's a good test :

- PAL : It looks like very flickering, the colors definitely don't blend
- NTSC : The colors blends pretty much OK, but you can see some interference going slowly downwards. Likely due to the difference between NES's almost 60Hz refresh and my 60Hz refresh.

My laptop screen only supports 60Hz refresh, so I can't change that. On my old CRT I could put it at 72 Hz, but I can't any longer.

EDIT : Oh in fact it supports 60Hz and 50 Hz. So I put it in 50Hz mode, and MAN THE FLICKERING IMAGES LOOKS RIDICULOUSLY BETTER. The colors blend together perfectly, you can still see that downwards interference.
Cry still looks bad (visible flickering on some colors + blocky), but the others looks amazing, with more colors.

So yeah this flickering method works only if the host's screen refresh rate is the same as the emulated NES.

To bad I'm afraid on real HW this won't work as well.

by on (#72530)
I updated the code to be both PAL/NTSC compatible with automatic detection, here's an example: http://thefox.aspekt.fi/nes/hui-ntsc.nes. I'll see about updating the rest of the images later. I don't have an NTSC console so I couldn't test this on real NES, so there might be attribute glitches. If somebody can test it for me I'd be grateful, altho it might be hard to spot the glitches on that specific image.

Bregalad wrote:
To bad I'm afraid on real HW this won't work as well.

Why is that? I don't think it should look too bad on a CRT. It does look like shit on my HDTV but that is to be expected when it treats the signal as 480i. Need to get me that upscaler...

by on (#72534)
As far as I can tell, hui-ntsc works on my NTSC frontloader + PowerPak + CRT SDTV, although I still notice flicker. One thing you could try is making sure that the total luma of all pixels in each 8x8 pixel tile of the image is the same in both frames. To calculate the luma of a gray pixel, take the "normalized" values from the brightness table. Colors $x1-$xC have luma values halfway between the corresponding grays $x0 and $xD; for example, $01-$0C is (0.397 +(-0.117))/2 = 0.140.

by on (#72538)
thefox wrote:
I updated the code to be both PAL/NTSC compatible with automatic detection ...

Awesome! Thumbs up. :D

by on (#72541)
NTSC versions, great! Can't wait to try them on hardware! =)

by on (#72546)
PAL/NTSC compatible versions of all images: http://kkfos.aspekt.fi/downloads/bunch- ... l-1-v2.zip

by on (#72548)
Quote:
Why is that? I don't think it should look too bad on a CRT. It does look like shit on my HDTV but that is to be expected when it treats the signal as 480i. Need to get me that upscaler...

It looks like shit indeed, interlacing lines instead of blending them doesn't look good.

I have no CRT hooked up right now so I can't confirm that, but I'm pretty sure every-frame-flickering was actually looking like flickering on my old CRT. SMB1 flickers mario every frame when he goes fire or super mario -> tiny mario, and he looks flickering, not trasnparent.
Also the batman intro looked horrible, that's what I meant in my first post.

by on (#72550)
For the record, I'm using an NTSC NES and LCD TV, I don't have any stutter or flicker at all. I don't even see a single tear in the image like emulators show during redrawing.

thefox: Looks perfect!

Now, for NTSC "High Hopes", right? ;P Or maybe you should just focus on that game you're making. :D

by on (#72555)
B00daW wrote:
Now, for NTSC "High Hopes", right? ;P Or maybe you should just focus on that game you're making. :D

NTSC High Hopes is probably not going to happen. Not that it wouldn't be possible, but it's just not worth the trouble. I'm planning to make a new demo though. :)

The game has many unknowns and a realistic estimate for completion is probably 5+ years. ;)

by on (#72689)
This is amazing! I've seen testi before too. :)

I wonder if you could somehow synchronize the flickering with a pair of shutter glasses for 3D effects! Not that I am super excited about 3D or anything, but it would be awesome if the NES could do that.

It'd be also interesting to see images like these converted for "cross eyed" 3D, just to see how much of the effect is retained:

Forest
Meal
Hallway

by on (#72714)
UncleSporky wrote:
I wonder if you could somehow synchronize the flickering with a pair of shutter glasses for 3D effects! Not that I am super excited about 3D or anything, but it would be awesome if the NES could do that.


Check this out:
http://famicomworld.com/system/other/3d-system/

There are glasses like that for the Vectrex, SMS, I don't know what else. I've been curious about it too, but it sounds like it's not much use for games.

Years ago I had wondered if it would be any better if you could synchronize 2 systems and somehow view each video (and sound) output separately. Probably not of any use, but at least it wouldn't flicker.

by on (#72715)
It was actually pretty fun, but the game library was a bit limited and it's not a huge success (possibly why it's not released for the NES overseas and games like Highway Star had to be changed to support Red/Blue glasses). As far as I remember the glasses were interchangeable with the SMS ones and the Laseractive and possibly other systems like the X68K (I actually bought a Laseractive one so that I could have two people seeing the effect at the same time), but the adapters were different. When Sega released the Japanese version of the SMS (i.e. not the original Mark III) it had the 3-D interface built-in and so one could just plug in the Nintendo glasses directly(and as far as I remember this was actually one of its selling points).

by on (#72867)
The Lost World one rocked! :D

by on (#73046)
I tested this in Nestopia and also FCEU GX for the Wii on a CRT (yay 240p!).

I am also very impressed. My favorite is kameli (the NES's blues and purples make that one look very natural, like the mountains in the background). testi (Jurassic Park) is also nice, and each frame is very detailed.

The flickering was bothersome in some pictures, but not others (like the one with the topless lady).

I'm interested in this, though... Assuming the NES had unlimited storage space, could you theoretically run many images in sequence at a good frame rate, for, say, videos?

by on (#73090)
devmas wrote:
I'm interested in this, though... Assuming the NES had unlimited storage space, could you theoretically run many images in sequence at a good frame rate, for, say, videos?


Check out the ROM by Dwedit in this thread. :)

by on (#73118)
Yes, and AFAIK the NES is the only console that uses the cartridge for VRAM. With bankswitching, there is no CPU cost to 'copy' all that data into memory instantly.

Don't forget these demos. It would be easy to speed it up by a huge margin with self-modifying, unrolled code. The resolution would be smaller, but you only have to write 1kB instead of 15kB? per frame.

by on (#73121)
Memblers wrote:
Don't forget these demos.

There's also this.

by on (#73160)
tokumaru wrote:
There's also this.


All of the demos linked to in this thread are awesome, but WOW! THIS demo is INCREDIBLY mind-blowing! My goodness! It was a immense shock to me when I loaded it up and experienced it in its entirety. I hope more people get a chance to see this.

Oh, and
Image

by on (#73162)
There are two other animation NES demos, ones which marked 001 and 002.

by on (#73164)
These animations are pretty cool. I'm a little disappointed because I found out that the animation and music in that Bad Apple demo wasn't made just for the demo. It's still pretty cool and it's obviously an impressive feat.

by on (#75646)
The Dinosaur looks like freakin' holographic 3D 0.0

by on (#82461)
I decided to release the tool which was used for these conversions. Download it HERE.

EDIT: Note: There's a small bug in the tool, there can't be spaces in the path of the image.

Basic usage

This tool takes a 256x480 or 512x240 resolution image and attempts to convert it to be displayed on NES to the best of its abilities. You can of course also convert a 256x240 image (so it won't flicker) by resizing it (using nearest neighbor filtering) to 256x480 or 512x240, then converting.

To use it, first of all you'll need to download and install ImageMagick (download the file ImageMagick-x.x.x-x-Q16-windows-dll.exe). After installing, open up command line and type "convert --version" to verify it installed succesfully. It should print something like this:
Code:
Version: ImageMagick 6.7.1-2 2011-08-02 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2011 ImageMagick Studio LLC
Features: OpenMP

You'll also need some version of the .NET runtime, I'm not exactly sure which. But you probably have it anyways if you're not using an ancient version of Windows.

In the package there's a file named "sample.png" which looks like this:

Image

Drag & drop "sample.png" over the file "convert-256x480.cmd". After a little while it should have been converted to "sample.nes". Open the ROM in your favourite emulator to verify it works. I prefer Nestopia, since it seems to be the best at keeping a stable frame rate. If it worked, CONGLATURATION!!! If not, drop me a line.

Preparing images for conversion (with Photoshop)

So how to prepare your own images for converting? You can't use just any arbitrary image. Here are the restrictions:

- Resolution must be 256x480 or 512x240.
- All colors in the image must be from Nestopia's YUV palette! Photoshop palette file is included in the package (nestopia-yuv-palette.act).
- Bit depth of the input image doesn't matter (at least 8 bpp and 24 bpp work).

Here's a process I've found to work fairly well for preparing arbitrary images. Let's take this random image from the internet for example:

Image

First I'm going to resize it down to 512x240 (from menu Image -> Image Size). 256x480 could be used as well, it's your choice. Looks like this:

Image

Now we need to reduce the number of colors in the image. Go to menu Image -> Mode and choose Indexed Color. This dialog will pop up:

Image

Color amount between 9-12 seems to work the best. The higher the number of colors, harder it is for the converter to give good results. I like to use Pattern dithering, but Diffusion can produce nice results as well.

The result looks like this:
Image

Next step is to make the colors compatible with NES palette. First we need to convert the image back to RGB. Choose to Image -> Mode -> RGB Color.

At this point it's usually good to make some adjustments to the image to make it better suited for NES. For example, pump up the contrast from Image -> Adjustments -> Brightness/Contrast. Image -> Adjustments -> Curves is another useful one. High contrast images tend to work better because there aren't very many shades of colors available on NES. The adjustments here are really the key to getting decent looking results, along with the complexity of the image.

Here's the image after my adjustments:
Image

Now let's apply the NES palette. Go again to Image -> Mode and choose Indexed Color. Under "Palette", choose "Custom...". In the "Color Table" dialog press "Load..." and navigate to the file "nestopia-yuv-palette.act". Be sure to turn Dithering off at this point! While it might look better, it'll make the image too complex to convert well. Take a look at the preview, and if it looks like shit, go back to adjusting the image.

Press OK, and here's the result:

Image

Now the image is ready to be converted. Save it in PNG format, and drag&drop the resulting PNG over "convert-512x240.cmd" to convert it. Pray to your deity of choice that it will be converted well.

Open the ROM in your favourite emulator to enjoy the fruits of your labor... It should look something like this:

Image

That's all! As usual, if you make something cool with this, let me know!

EDIT: Forgot to mention, in this latest version of image viewer button A can be pressed to skip over one frame, making it possible to adjust the even/odd field on displays such as HDTVs which treat the signal as interlaced. This can be used to make 256x480 images look better (or rather, a little bit less bad) on those displays.

by on (#82480)
Cool, I can't wait to get back home to try it.

by on (#82771)
Quote:
To use it, first of all you'll need to download and install ImageMagick.

Dead link

by on (#83815)
That composite shot reminds me of why many Genesis/MD artists have used vertical dithering (well, now that I think about it, it's more accurately termed horizontal dithering). No vertical blending means that dithering on the Y axis sticks out like a sore thumb. Give me a bit to get back to my PC and I'll post my ImageMagick dithering threshold map for doing X-only dithering (and I'm experimenting with a technique to flip the map and make fieldrate flickering acceptable in many more cases so that might be useful too - C64 democrews have flickered for years without complaint, and they're primarily PAL). ImageMagick can also take a second input image containing the target colorset (which can hold more than 256 colors, btw), which is really handy for making proper 9-bit images for the MD and would also be useful for targeting either the YUV or RGB palette for the NES.

I'll also do a test using that same image, with the only change to your script being to use my X-only dithering map (well, that and moving the color reduction from Photoshop to ImageMagick, using a remap image derived from your Photoshop palette).

Edit: After doing some experiments, it turns out that things don't work so well with the flickering (although part of the difficulty is the non-RGB palette of the NES, as the -remap parameter is a color reduction step, not just a color mapping tool, so I'm finding it a pain in the ass to make IM use the PPU YUV palette as the colormap to reduce to, and same thing with the -colors switch). Am I just having trouble grokking IM or is what I'm wanting to do only possible with IM for the MD because of the regular 8-level RGB?

by on (#83836)
Bregalad wrote:
Quote:
To use it, first of all you'll need to download and install ImageMagick.

Dead link

Sorry, missed this earlier. Fixed now.

LocalH wrote:
ImageMagick can also take a second input image containing the target colorset (which can hold more than 256 colors, btw), which is really handy for making proper 9-bit images for the MD and would also be useful for targeting either the YUV or RGB palette for the NES.

Yep, but the resulting images are usually way too dithered to work well on the NES, that is, they contain way too many colors inside an attribute block. Dithering to an arbitrary colorset can be done with Photoshop as well (and at least previously Photoshop's dithering algorithms looked much better than ImageMagick's), but like said, it just doesn't work very well.

The attribute limitations really are a pain in the ass for realistic images like these.

Quote:
After doing some experiments, it turns out that things don't work so well with the flickering (although part of the difficulty is the non-RGB palette of the NES, as the -remap parameter is a color reduction step, not just a color mapping tool, so I'm finding it a pain in the ass to make IM use the PPU YUV palette as the colormap to reduce to, and same thing with the -colors switch). Am I just having trouble grokking IM or is what I'm wanting to do only possible with IM for the MD because of the regular 8-level RGB?

I'm not sure.

Btw here are some new images I've converted: http://thefox.aspekt.fi/new-images.zip (Nestopia preferred, it seems to be the best at keeping a stable framerate).

by on (#83968)
Very nice images, the use of alternation at the frame rate (I call it "color-interlacing" from my days learning about the C64) is quite good for color blending (as long as the two colors being alternated are similar in luminance, obviously alternating black and white is not good). It would certainly be nice if the NES had a way to shift the image by a half-pixel, then you could also simulate double horizontal resolution (like they do on the C64 by using two multicolor images, which of course use double-wide pixels, and then one of the two images is offset by one hires pixel in hardware). And still in such cases you'd only really get good results on RGB PPUs, as the composite color phasing interferes with precise NES pixel placement.

by on (#84468)
Theoretically, couldn't you change the palette as the PPU draws the frame (per pixel or per tile) and get dramatically more colors?

by on (#84469)
You can, but the screen needs to be turned off for about a scanline worth of time. And you'll see the colors you write to the palette drawn on the screen.

by on (#84472)
Very nice application, thanks for the long description!
I was able to do a nice famicom picture but I wasn't able to use the palette provided, I'm using PaintshopPro and every palette editor is showing "wrong file" when trying to open your *.act palette :(

by on (#84473)
Zelex wrote:
Theoretically, couldn't you change the palette as the PPU draws the frame (per pixel or per tile) and get dramatically more colors?

That works for a few special cases like Blargg's flowing palette demo (video; discussion).

by on (#84491)
This also makes me wonder if a Mode 7 like effect is possible on the NES.

by on (#84493)
Go play some Cosmic Epsilon, it's the closest you'll get.

by on (#84498)
Dwedit wrote:
Go play some Cosmic Epsilon, it's the closest you'll get.

Well, I'll be damned. Thats pretty awesome and it even works in my emulator too.

by on (#84499)
Zelex wrote:
Thats pretty awesome and it even works in my emulator too.

It's a clever CHR bankswitching trick. The game has CHR data for a number of horizontal patterns with perspective, and different patterns can be displayed in a single frame through bankswitching. Animation is achieved by moving the bankswitching spots every frame. Unfortunately, this trick can't be used for rotations.

by on (#84510)
I've always found that Cosmic Epsilon looks less impressive than Rad Racer games. Just that recatnagular patterns looks less impressive than a road I guess....

by on (#84885)
jpx72 wrote:
Very nice application, thanks for the long description!
I was able to do a nice famicom picture but I wasn't able to use the palette provided, I'm using PaintshopPro and every palette editor is showing "wrong file" when trying to open your *.act palette :(

I needed the palette in another format for GraphicsGale recently, it seems to use the same PaintShop Pro file format so here it is: http://thefox.aspekt.fi/nestopia-yuv-palette.pal

by on (#84911)
Thanks! I've been waiting for that!

by on (#86943)
I've registered on this message board just to say thanks to thefox for this wonderful program.
I'm having a lot of fun converting images to .NES files.

Some of my image convertions:
The Revenge of Shinobi Title Screen: http://www.4shared.com/file/ZkoqBvFi/th ... tle_s.html
Altered Beast 1st transformation: http://www.4shared.com/file/AzrlxtwN/Al ... n_by_.html
Ghostbusters updated title screen: http://www.4shared.com/file/zJBmhmEZ/Gh ... _by_M.html

Thanks again thefox! =)

by on (#86944)
Use mediafire instead, no wait time on downloads.

by on (#86945)
Dwedit wrote:
Use mediafire instead, no wait time on downloads.


Thanks for the tip ;)

by on (#87130)
Question : is there a way to get a converted image that isn't "shaky" ?
I just hate how shaky the resluting NES ROMs are, I understand you want this effect to add more colors but it really looks terrible on my computer.

PS : Also, is there a way to prepare the images for conversions without using a pay-ware (fotshop) ? Because the results looks horrible if I don't prepare them for conversion.

by on (#87132)
As I said before, there's one way to avoid shakiness in this temporal dithering, and that's to make sure the luma of each tile is roughly the same between frames. To estimate luma:
  • Add 0 for each black pixel.
  • Add 1 for each pixel using $01-$0C.
  • Add 2 for each pixel using $00 or $11-$1C.
  • Add 4 for each pixel using $10 or $21-$2C.
  • Add 5 for each pixel using $31-$3C.
  • Add 6 for each white pixel.

Or are you trying to say you don't want to use two frames at all?

by on (#87137)
Bregalad wrote:
Also, is there a way to prepare the images for conversions without using a pay-ware (fotshop) ?

Who the hell pays for Photoshop? I imagine that only companies do, since most common users can't spend that much on a single software. If you really don't want to do anything illegal, I'm sure that GIMP can be used for this preparation process.

by on (#87138)
College students with student discounts.

by on (#87140)
Not everybody who has already graduated can afford to go back to college.

That said, I was under the impression that GIMP's color quantization isn't quite the same as that of Photoshop. I'll look through the directions to see what of them I can translate to GIMP's menu structure.

[tepples looks at the previous page]
I guess I'll have to be the first one to try using Mono as "some version of the .NET runtime".

[tepples tries running one of the .cmd files one line at a time, translating Windows-isms into Unix-isms by hand]

Code:
pino@pino-laptop:~/Desktop/testing/bin$ ./nesconv.exe even.png
Missing method EnableVisualStyles in assembly /home/pino/Desktop/convert/bin/nesconv.exe, type System.Windows.Forms.Application

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies.
File name: 'System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
[ERROR] FATAL UNHANDLED EXCEPTION: System.IO.FileNotFoundException: Could not load file or assembly 'System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies.
File name: 'System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
pino@pino-laptop:~/Desktop/testing/bin$ sudo apt-get install libmono-winforms4.0-cil
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package libmono-winforms4.0-cil
E: Couldn't find any package by regex 'libmono-winforms4.0-cil'


It appears to depend on a version of that's not part of the version of Mono that comes with my operating system. Any idea where I can get the right version of System.Windows.Forms for Mono, other than by buying a copy of Windows XP, Windows Vista, or Windows 7 to run in VirtualBox?

by on (#90857)
I'm still having a lot of fun with this program.
I even started a blog with title screen remakes of classic games (all created with NES Image Converter): http://mcbremakes.blogspot.com/

Thanks again for this wonderful software!
Macbee

by on (#90868)
I recently found out there's a nice feature in Photoshop called "Actions" which allow you to record a list of actions taken (like a macro) and then rerun it later. This makes it much easier to test different configurations of contrast/dithering/etc on images to be converted to find out what settings give the best results.

--

Bregalad wrote:
Question : is there a way to get a converted image that isn't "shaky" ?
I just hate how shaky the resluting NES ROMs are, I understand you want this effect to add more colors but it really looks terrible on my computer.

Just make the image at 256x240 resolution and resize (nearest neighbor, that is no filtering) to 512x240 or 256x480, then convert.

Quote:
PS : Also, is there a way to prepare the images for conversions without using a pay-ware (fotshop) ? Because the results looks horrible if I don't prepare them for conversion.

You can use Imagemagick or any other tool that allows mapping to a specific palette, but I never got as good results out of Imagemagick as Photoshop.

Macbee wrote:
I'm still having a lot of fun with this program.
I even started a blog with title screen remakes of classic games (all created with NES Image Converter): http://mcbremakes.blogspot.com/

Thanks again for this wonderful software!
Macbee

Pretty cool stuff, you're welcome!

by on (#94497)
I just had to try it from scratch, since I couldn't get the converter tool working. a lot of trial & error between GIMP, mspaint and Nesst but I finally got the basic idea. it might flicker a little due to the contrast difference between the 2 frames but it's no worse than I expected. anyway here's my attempt:


https://www.dropbox.com/s/48a45c0pl03hpib/inta.zip


I couldn't quite figure out how to split an image into two interlaced frames so i just found two other elements to split it into, the red colour channel and the blue/green (cyan) colour channel. I've yet to try it on a CRT with a devcart but i'm hoping the flicker won't be as noticeable...

by on (#94501)
To split an image into interlaced pairs in GIMP, try using "erase every other row" then copy and paste a pixel up or down.

I'd recommend splitting into green and magenta planes, as the eye is more sensitive to green detail. I'd also recommend switching between the images per scanline if possible. Should I make my own ROM to demonstrate this?

by on (#94504)
It doesn't work very well on the NES...

I get a different color base and graphics glitch on each power up. Usually it won't run at power up either, you've got to hit reset.

Realize the colors aren't what they should be but the flickering is pretty noticeable.

by on (#94513)
infiniteneslives wrote:
I get a different color base and graphics glitch on each power up. Usually it won't run at power up either, you've got to hit reset.


my bad...in my rushed programming I often forget to clear PPU and RAM which often reveals glitchy data when I finally run the program on NES hardware

tepples wrote:
I'd also recommend switching between the images per scanline if possible. Should I make my own ROM to demonstrate this?


I thought that any mid-rendering PPU operation beyond a Sprite Zero Hit required timed code or an IRQ timer...

by on (#94514)
I guess my real question is: could the average player handle playing through an entire Shadowgate-style RPG made of images of this quality?

by on (#94515)
I shopped up something quick in GIMP as a demonstration.

ImageImage
Green and magenta channels from this render

Image
Green and magenta channels summed (not possible on NES)

Image
Channels displayed in alternate frames (trivial on NES)

Image
Channels displayed on alternate scanlines (far more stable-appearing; requires one scroll change per scanline on NES)

If the last picture is acceptable to players, then of course a point-and-click-fest would be possible on an NES.

by on (#94516)
so...that means on one fully rendered frame there would be all the even scanlines of the Magenta channel / odd scanlines of the Green channel ; and on the next frame it would be evens-green/odds magenta?

by on (#94517)
Correct. How does it look in the GIF? Should I try making a ROM next to demonstrate?

by on (#94521)
Those last two examples would look the same on my TV, actually; it combines two interlaced frames into one image.

by on (#94545)
would you do it using timed code to change $2005 and $2000.1 every scanline? would there be any time left to run a game engine after that? maybe if the engine started running halfway down the screen...

by on (#94547)
Roni wrote:
would you do it using timed code to change $2005 and $2000.1 every scanline?

I think it's just one write to $2000.0 per scanline with vertical mirroring, or one write to the mapper per scanline with 1-screen mirroring. Both nametables have the same tile numbers loaded into them, just different attributes.

Quote:
would there be any time left to run a game engine after that? maybe if the engine started running halfway down the screen...

You mentioned Shadowgate. A turn-based graphical adventure or visual novel like Shadowgate or Myst or Ace Attorney series could certainly get away with running the engine halfway down. Mapper support to switch between nametables after each scanline (similar to the pattern table switching of MMC2) could make it even easier.

by on (#94552)
I am thinking a seamless optimized blend of high and low-res regions with the text superimposed incidentally, perhaps by mapping the text over each tile in chr-ram. maybe SxROM can do this?

by on (#94580)
I forget...how many NES CPU cycles long is an NTSC scanline? is it a whole number? IIRC I can't use simple timed code, like NOP strings, to land on each scanline.

by on (#94582)
For NTSC and Dendy, 341 ppu dots is 113.66666 CPU cycles per scanline.
For PAL, I think it's 106.5625 CPU cycles per scanline.

by on (#94587)
In Zap Ruder, my Zapper experiment ROM, the "zapkernels" are responsible for measuring how far down the screen the Zapper is pointed. What they do is add 256*2/3 to a variable every scanline and use BCS to waste an average two-thirds of a cycle in the branch taken penalty.
Code:
  clc
  lda subcycle
  adc #$AA
  sta subcycle
  bcs :+
:

That said, I'm working on collecting some pictures to make a slideshow ROM.

by on (#94652)
it was tough, but I got it pretty damn close...using a whole bunch of test code that is now vestigial :P

I had to forgo toggling the color emphasis bits as it seemed not to work the way I wished. is it not possible to toggle that register between scanlines?

by on (#94658)
Good job. On hardware (PowerPak), there are artifacts to the left and right of the top half of the picture, as if the nametable isn't getting completely cleared. But I'd advise against using the emphasis bits for anything important. They screw up on PlayChoice, Famicom Titler, and some famiclones.

I'm still working on my own photograph to NES conversion path. It tries to work around the strong diagonal lines that dithering causes by intentionally triggering the 3-phase colorburst sequence. Look at my pictures:

RGB121 demo

by on (#94677)
That looks really good, tepples! The flickering is much less distracting than it usually is with these pictures! The photographs look great, better than most Sega CD FMVs, I think!

by on (#94691)
It looks REALLY good now Roni! There is effectively no jitter or movement. Here's a pic incase you're not able to see if for yourself, the emu doesn't do it justice.

Image

Your slide show is pretty interesting Tepples. The 'motion' is difficult to ignore but the images still look really good and portray the image well IMO.

by on (#94710)
yeah, the lines are quite noticeable, especially when I shake my eyes at it.
Re:
by on (#97765)
tepples wrote:
Good job. On hardware (PowerPak), there are artifacts to the left and right of the top half of the picture, as if the nametable isn't getting completely cleared. But I'd advise against using the emphasis bits for anything important. They screw up on PlayChoice, Famicom Titler, and some famiclones.

I'm still working on my own photograph to NES conversion path. It tries to work around the strong diagonal lines that dithering causes by intentionally triggering the 3-phase colorburst sequence. Look at my pictures.


Impressive!! Is there a tutorial to create slideshows of interlaced images just like yours?
I'm still playing with NES image converter every day (see results on http://mcbremakes.blogspot.com.br/ ) - and I'd love to be able to make slideshows like this. :D
Re: Re:
by on (#97767)
Macbee wrote:
I'm still playing with NES image converter every day (see results on http://mcbremakes.blogspot.com.br/ ) - and I'd love to be able to make slideshows like this. :D

The Predator and Superman ones look nice. One of those back in the day would have definitely kicked some ass. :)
Re: Re:
by on (#97772)
thefox wrote:
Macbee wrote:
I'm still playing with NES image converter every day (see results on http://mcbremakes.blogspot.com.br/ ) - and I'd love to be able to make slideshows like this. :D

The Predator and Superman ones look nice. One of those back in the day would have definitely kicked some ass. :)


Thanks thefox! I'm very happy to know you liked something I've created with your software.
By the way are you planning to update it? It's a near-perfect program to me but I always wonder if you have plans to add EVEN MORE amazing features there. :D
Re: Re:
by on (#97779)
Macbee wrote:
By the way are you planning to update it? It's a near-perfect program to me but I always wonder if you have plans to add EVEN MORE amazing features there. :D

Not in the near future. I originally wrote the tool so I could use it in a demoscene production, so if/when I start to work on a new demo I might revisit the tool. It definitely should be possible to improve the results.

I could document the image viewer data layout though, if somebody else wants to make a converter to the same specs. The format is kind of already documented in "concat.c" file that's included with the tool. It goes like this:
Code:
PRG data:
- OAM data for the 1st frame (using 8x16 sprites)
- OAM data for the 2nd frame
- Palette for the 1st frame (32 bytes)
- Palette for the 2nd frame
- Attribute data for the even attribute rows of the 1st frame (attributes cover a 16x8 area)
- Attribute data for the odd attribute rows of the 1st frame
- Attribute data for the even attribute rows of the 2nd frame
- Attribute data for the odd attribute rows of the 2nd frame
CHR data:
- Background CHR tiles for the 1st frame (covering a 32*30 tile area, so 32*30*16 = 15360 bytes, padded to 16 KB)
- Background CHR tiles for the 2nd frame
- Sprite CHR tiles for the 1st frame (2 tiles for all 64 8x16 sprites, so 128*16 = 2048 bytes total)
- Sprite CHR tiles for the 2nd frame

I know, the format isn't size efficient, but that was not the point of this tool.
Re: Some image conversions I made
by on (#106150)
I should rewrite this tool some day, I just noticed it makes some obviously wrong choices in some trivial pictures. E.g. if image is mostly black, and contains just some white, for some reason it makes the entire palette black. And sometimes it only fills the first 4 palette colors even though there are other colors in the source image. Seems to be a bug in the palette selection algorithm.
Re: Some image conversions I made
by on (#106168)
thefox wrote:
I should rewrite this tool some day, I just noticed it makes some obviously wrong choices in some trivial pictures. E.g. if image is mostly black, and contains just some white, for some reason it makes the entire palette black. And sometimes it only fills the first 4 palette colors even though there are other colors in the source image. Seems to be a bug in the palette selection algorithm.

I can't wait for an update :D
I've made almost 400 conversions using this software for last 14 months. Probably 99% of all posts on my blog are Roms made with the help of 'Nes Image Converter'.
Many people here in Brazil likes this tool too. I'm about to write a Brazilian Portuguese tutorial for friends on a big Message Board.

But yeah, the only flaw of "NIC" is related to some wrong color conversions (not that I'm complaining - I'm just trying to inform some bugs).
I use to have 4 problems there:

1- Color 00 is ALWAYS converted to black. It will never appear as the color it should (dark grey)
Solution: I have to manually edit the rom on a Hex editor and change the wrong color to 00.

2- "Minimalistc" images (with few graphics of few colors) usually aren't good candidates for conversion.
Take this 4-color vertical gradient image for instance: http://i5.photobucket.com/albums/y191/m ... d8f1b5.png
Solutions: Images with a few colors usually have to be VERY detailed to be successfully converted.
Images with a few graphical elements need to have many irrelevant extra drawings added on Photoshop - to be manually removed later on progams like YY-CHR.

3- Images with many colors will hardly work. During my tests only one 12-color image was properly converted. This one: http://i5.photobucket.com/albums/y191/m ... df8ad9.png
Solution: Make images up to 7 colors. A 7 color image is usually properly converted.

4- Some random images aren't properly converted no matter how I try to optimize them.
Like this one for instance: http://i5.photobucket.com/albums/y191/m ... 40e259.png (not even reducing the number of colors will make it work).
Solution: Move over to another project. Seems there's nothing to do.

===================================================================

I also have five gazillion suggestions for new features but I'll spare you from it.
The only one I would *REALLY* like to see would be a way to also send two images (instead of only one) to NIC.
A new version of NIC could have 3 modes of conversion:

Mode 1 (1 image required) - The same, intact conversion method we already have on current Nes Image Converter.
It's perfect for conversion of photographs and all sorts of line-flickering images.

Mode 2 (2 images required) - User would provide both "odd" and "even" images. It would be perfect to make checkerboarded pattern images for instance (today I have to create 2 roms, mix them, edit many unmatching sprites on YY-CHR and colors on Hex editors to achieve this).

Mode 3 (2 images required) - First image would be made ONLY of background tiles. And second one would be made ONLY of sprites. Instead of a 2-frame screen, both images would be blended into a single screen (final result would be something like characters standing on a background). It would be perfect to create fake, static in-game images.

===================================================================

Feel free to ignore my suggestion but let me thank you again for NIC, thefox.
It's probably the most entertaining and educational NES-related tool (for non-programmers) ever released.
Re: Some image conversions I made
by on (#109027)
Macbee wrote:
But yeah, the only flaw of "NIC" is related to some wrong color conversions (not that I'm complaining - I'm just trying to inform some bugs).
I use to have 4 problems there:

Thanks for the feedback, and sorry for not replying earlier.

I checked the source code some time ago and I immediately spotted causes of some of those bugs. Unfortunately the code is so bad I'd rather rewrite it than try fixing it. One of these days...
Re: Some image conversions I made
by on (#109227)
thefox wrote:
Macbee wrote:
But yeah, the only flaw of "NIC" is related to some wrong color conversions (not that I'm complaining - I'm just trying to inform some bugs).
I use to have 4 problems there:

Thanks for the feedback, and sorry for not replying earlier.

I checked the source code some time ago and I immediately spotted causes of some of those bugs. Unfortunately the code is so bad I'd rather rewrite it than try fixing it. One of these days...


You're welcome thefox! It was a pleasure to help.
Re: Some image conversions I made
by on (#114256)
I decided to completely rewrite this tool over the previous weekend. It now has a proper GUI and a much less buggy conversion algorithm. Hopefully the results are a little bit better as well. Here's a screenshot:

Attachment:
nes-image-converter-2-shot.png
nes-image-converter-2-shot.png [ 72.53 KiB | Viewed 4874 times ]

And here's the download: http://kkfos.aspekt.fi/downloads/nes-im ... -2-v01.zip

Sorry for the bloated size, Qt 5 includes 20 MB worth of internationalization DLLs in its default build.
Re: Some image conversions I made
by on (#114324)
Nice work! I'm sure it can be extracted back out again without too much effort, but it would be nice if the NT/AT/PT/pallettes could be exported as raw files vice just .nes I don't see the concat.c file included anymore does the file layout you gave previously still apply? I'm guessing the code follows the attribute data in the PRG bank, any chance to get the source for that? Not a big deal to recreate though I guess.

I've had very little luck with tools that were supposed to help with conversion in the past. This goes leaps and bounds towards delivering output from a generic image input. The flickering image is great and all, but just having a still image would be plenty for some of the uses I have in mind.

If I'm missing something let me know, but I can find an easy way to get an output from this I can import into anything other than by disassembling the rom again. Due to the size and in-efficiencies it doesn't sound like the goal of all of this was to have the output imported into games, but it's really not that bad considering how cheap bits are these days.
Re: Some image conversions I made
by on (#114326)
infiniteneslives wrote:
Nice work! I'm sure it can be extracted back out again without too much effort, but it would be nice if the NT/AT/PT/pallettes could be exported as raw files vice just .nes I don't see the concat.c file included anymore does the file layout you gave previously still apply? I'm guessing the code follows the attribute data in the PRG bank, any chance to get the source for that? Not a big deal to recreate though I guess.

Yeah the ROM file format has stayed the same. The code isn't entirely trivial, because it needs to switch the CHR bank multiple times midscreen and also because of the 16x8 attributes. Source is not available at this time. :)

Quote:
I've had very little luck with tools that were supposed to help with conversion in the past. This goes leaps and bounds towards delivering output from a generic image input. The flickering image is great and all, but just having a still image would be plenty for some of the uses I have in mind.

If I'm missing something let me know, but I can find an easy way to get an output from this I can import into anything other than by disassembling the rom again. Due to the size and in-efficiencies it doesn't sound like the goal of all of this was to have the output imported into games, but it's really not that bad considering how cheap bits are these days.

Right now it's not possible to get the individual files. And yeah the goal of the tool was to be more of an toy than to help in game development.

Also note that the tool uses 16x8 attribute area so the results aren't directly usable anywhere else without timed code. It would be fairly easy to add an option for 16x16 attribute area (and other sizes such as 8x8, 8x1 etc), and maybe an option for reserving some palette entries for other purposes, so those features may come one of these days.
Re: Some image conversions I made
by on (#114327)
Fair enough, I'll poke around with it then when my next image conversion task arises. Thanks for clarifying some of the details.
Re: Some image conversions I made
by on (#114329)
thefox wrote:
(and other sizes such as 8x8, 8x1 etc), and maybe an option for reserving some palette entries for other purposes, so those features may come one of these days.
Since the InviteNES is apparently going to support 8x1 attribute zones for the selection menu, it'd be wonderful if you'd spare me from the compulsion to build that converter. ;)
Re: Some image conversions I made
by on (#114394)
lidnariq wrote:
thefox wrote:
(and other sizes such as 8x8, 8x1 etc), and maybe an option for reserving some palette entries for other purposes, so those features may come one of these days.
Since the InviteNES is apparently going to support 8x1 attribute zones for the selection menu, it'd be wonderful if you'd spare me from the compulsion to build that converter. ;)

Yeah I wrote the program with other attribute sizes in mind so the feature should be easy to add. The only reason I didn't include it yet is that there's no standardized way to structure such data (of course I could always export something like JSON which the user could process to his liking... but we'll see).