Pictoric (was: New conversion algorithm)
Re: New conversion algorithm
The algorithm should keep oric-compliant images[*] as is. One can check that the total error in the picture is 0 in that case (see highlighted value in screenshot below), meaning that no pixel where harmed during the process.
___
[*] 240x200 pixels, columns 1 to 6 left blank (the algorithm will ignore these pixels anyway), only 8 full-saturated colors max, and same proximity constraints as oric video.
___
[*] 240x200 pixels, columns 1 to 6 left blank (the algorithm will ignore these pixels anyway), only 8 full-saturated colors max, and same proximity constraints as oric video.
Re: New conversion algorithm
This is because in the code I have put this protectionThe algorithm doesn't do anything special to those 6 pixels, it is just that I thought that colored pictures always need to have these 6 black pixels in the start of a line to make early changes in the ink more easy. Maybe I can remove this in case of gray-scaled picture since then there is no need for ink-changes. Prepare for a future update then
I you dare the experimentation, you can remove that"if x<6" line and see the result on coloured pictures. Results might be interesting (or disgusting... ymmv)
Code: Select all
local function getLinearPixel(x,y)
if x<6 then return Color:new() end -- first 6 horiz pixels are reserved
I you dare the experimentation, you can remove that"if x<6" line and see the result on coloured pictures. Results might be interesting (or disgusting... ymmv)
Re: New conversion algorithm
It's very common to have Oric pictures (or game screens) start with a PAPER color attribute, sometimes displayed in inverted video to give a different colorit is just that I thought that colored pictures always need to have these 6 black pixels in the start of a line to make early changes in the ink more easy
A good example would be a picture frame: You would have the frame in a particular color, then the canvas in another color, and the portrait on the canvas. You can totally do that on the Oric with putting an inverted PAPER attribute all around (including first 6 pixels), then your normal PAPER color will continue to display itself as background canvas color, which means you can just use your ink changes just after (they will appear as paper color).
EDIT: There's a bunch of pictures here you can test with: http://miniserve.defence-force.org/view ... lope/data/
Re: New conversion algorithm
I can't get any of the binary file from the svn browser (it shows as ascii, see >>this<<). What's the trick?
I can make that 6 pixel blank margin an option changeable with a flag. But how to detect that the flag is to be set to true or false ? I don't see any well defined decision procedure here: which is best?
1) always black which is more consistent or
2) let the algorithm decide even if this produces weird artefacts of little weight on the total error, but still very visible to the human eye (which prefer regularity.)
[EDIT] Oh! I have an idea. I need to experiment on the images of the SVN (once I can download them successfully )
I can make that 6 pixel blank margin an option changeable with a flag. But how to detect that the flag is to be set to true or false ? I don't see any well defined decision procedure here: which is best?
1) always black which is more consistent or
2) let the algorithm decide even if this produces weird artefacts of little weight on the total error, but still very visible to the human eye (which prefer regularity.)
[EDIT] Oh! I have an idea. I need to experiment on the images of the SVN (once I can download them successfully )
Re: New conversion algorithm
This link should work for direct download: http://miniserve.defence-force.org/svn/ ... lope/data/
- ibisum
- Wing Commander
- Posts: 1652
- Joined: Fri Apr 03, 2009 8:56 am
- Location: Vienna, Austria
- Contact:
Re: New conversion algorithm
I'm so glad you did this project in Lua, its my favourite of all languages..
This afternoon I'm sitting down to use it to build a small art installation which utilises an Atmos I've recovered.
Can I perhaps assist with the repository duties? Only thing you have to do is name the project, and I'll set everything up so that we can have a proper tool that does the Magic. "Oric_tst5.lua" isn't good, maybe you've got a better name for the tool?
If we have a repo, we can share updates/fixes/tweaks, and .. oh man .. having Oric tools in Lua is making me really, really happy. So, you know .. just raising my hand to take on repo duties, if you need/want such a thing.
This afternoon I'm sitting down to use it to build a small art installation which utilises an Atmos I've recovered.
Can I perhaps assist with the repository duties? Only thing you have to do is name the project, and I'll set everything up so that we can have a proper tool that does the Magic. "Oric_tst5.lua" isn't good, maybe you've got a better name for the tool?
If we have a repo, we can share updates/fixes/tweaks, and .. oh man .. having Oric tools in Lua is making me really, really happy. So, you know .. just raising my hand to take on repo duties, if you need/want such a thing.
Re: New conversion algorithm
I got a newbie question. Take for instance Milou in the picture of "Tintin et les Cigares du Pharaon". Milou is all white on the original picture, and IIRC there were dots on him on the final Oric picture.
Could there be a kind of second pass to check the surfaces colour and remove the "dithering that shouldn't be there" on "clean surfaces that have a coulour close to existing Oric coulour" ?
I suspect those dots were here because it wasn't exactly *white* on the original picture, but maybe a bit darker.
Could there be a kind of second pass to check the surfaces colour and remove the "dithering that shouldn't be there" on "clean surfaces that have a coulour close to existing Oric coulour" ?
I suspect those dots were here because it wasn't exactly *white* on the original picture, but maybe a bit darker.
Re: New conversion algorithm
I have just checked >>this<< and >>that<< picture, and milou isn't white. It is #FDFAE9 and #EFEFEF respectively. This probably explains the small dark spots, but I need to check the original I have at home(still at work atm.. ush!! ). [EDIT] in the picture at home milou isn't fully white too.
If you wan't to have a cleaner image, you can modify the saturation of the colors and the white-balance on the image before converting. The tool itself tries to respect the hue&saturation of the colors it was given. It'll just push the luminosity to full range, because it makes the image more clear IMHO (see the normalization parameter in the file).
@ibisum Glad you enjoy lua. This mean you can understand the source. It isn't finished yet. I should add a GUI to alter the various parameters in a easy way on both the cmd-line and in GrafX2.
Do you have a name to suggest? tst_oric5 is just my internal work-in-progress name. (I have one in mind since 5pm (guess why), but couldn't connect it with the tool: Tea-Oric ? ) [EDIT or since I live in french britany atm... arm-oric ]
If you wan't to have a cleaner image, you can modify the saturation of the colors and the white-balance on the image before converting. The tool itself tries to respect the hue&saturation of the colors it was given. It'll just push the luminosity to full range, because it makes the image more clear IMHO (see the normalization parameter in the file).
@ibisum Glad you enjoy lua. This mean you can understand the source. It isn't finished yet. I should add a GUI to alter the various parameters in a easy way on both the cmd-line and in GrafX2.
Do you have a name to suggest? tst_oric5 is just my internal work-in-progress name. (I have one in mind since 5pm (guess why), but couldn't connect it with the tool: Tea-Oric ? ) [EDIT or since I live in french britany atm... arm-oric ]
Pictoric (was Re: New conversion algorithm)
Okay.. I tested the idea and it worked well. By default the algorithm uses a heuristic to guess wether or not the first octet of each line should be kept blank or not. Oric's compliant images from the SVN get all their left column unchanged, and even some pictures from the internet do (like this one). This is good result.
So I decided to release v1.0 of the tool as I don't think there will be more research on the algorithm. That version doesn't contains yet support to change parameters from the GUI or from the command line because I wanted to have a K.I.S.S. for a start (keep it simple solution), but it contains a name for the tool/algorithm which I let you discover. A full-featured version for windows users which includes both lua & convert utilities is temporary downloadable (during one week) via >>this link<<.
- Attachments
-
- Pictoric_v1_0.zip
- Official V1.0 of the conversion algorithm.
- (11.67 KiB) Downloaded 265 times
Re: Pictoric (was: New conversion algorithm)
- Attachments
-
- forest_dragon.tap.png (4.97 KiB) Viewed 10940 times
-
- floating_on_air.tap.png (5.08 KiB) Viewed 10940 times
-
- a_place_to_be.tap.png (5.77 KiB) Viewed 10940 times
Re: Pictoric (was: New conversion algorithm)
Edward Munch's Scream... Impressive
And girl with pearl earring
Dali, of course
And girl with pearl earring
Dali, of course
- ibisum
- Wing Commander
- Posts: 1652
- Joined: Fri Apr 03, 2009 8:56 am
- Location: Vienna, Austria
- Contact:
Re: Pictoric (was: New conversion algorithm)
Really nice! The only thing I don't like about this project is that there isn't a GIT Repo for it yet ..
Re: Pictoric (was: New conversion algorithm)
@peacer: If you take the generated pictures and clean the noise pixels (like for example the blue and white dots on the background of the girl with pearl earring or the green pixels at the bottom of the dali, and you reconvert the picture, do you get an even better result?
Re: Pictoric (was: New conversion algorithm)
Yes, its possible to retouch the images to remove those noise pixels
But I think, re-conversion looses some "good" pixels too and result is not satisfactory as original ones..
But I think, re-conversion looses some "good" pixels too and result is not satisfactory as original ones..