I am trying to create a piece of software that can be used to create VERY large (10000x10000) sized bitmaps. All I need is something that can work in monochrome, since the required output is a matrix containing details of black and white pixels in the bitmap. The closest thing I can think of is a font editor, but the size is a problem.
Is there any library out there that I can use to create the software, or will I have to write the whole thing from the start?
Edited on May 25: OK, so I've been searching around and I have found that using the GtkTree Widget is a good way to create grids. Has anybody tried that with the large sizes that I require? And if so, can it be made to look like a drawing surface rather than a Spreadsheet like view?
Why don't you use bitmap objects, like gdk pixmaps if you use GTK?
10,000 x 10,000 pixels with a depth of 1 (monochrome) is 100,000,000 bits, which is 12,500,000 bytes, around 12 megabytes.
Not that large.
Related
I read some of those website links that explain about exporting different image sizes for iOS device. But I don't really understand of those explaining. (May be I am not good at in English language.)
I found these dimension for launch screen. Please let me clarify my understanding to you guys.
So, when I create an image, I must create a larger size(#3x) firstly and should export that image into smaller sizes (#2x, #1x). Am I right?
For example, I create 1242x2208px (3x) image and scale to 2x,3x and save.
My questions are that;
1) I draw images in Photoshop CS6.For any size of images, the Resolution is still 75px. isn't it?
So, for 1242x2208px(3x) size , the resolution is 75px and then I decrease the size. The image will small and does it get blurry appearance?
2) Does image elements (heart image in my example image)need to make to be large in smaller device(1x) to get the clear looks? Or
3) If we don't need to modify image elements or may be some texts of font size to be large or small, can we get the high resolution of image appearance in 1x? I'm afraid that if we scale to smaller(1x), it would be blur and not good in looks because we are still in 75 resolutions.
4) Does it need to make to fit the image elements to image size? I found this video https://www.youtube.com/watch?v=WOnczJSsMqk . In this video, he crops the white space and export into #1x, #2x and #3x. So, the size of #3x is not the image size from Apple official Guideline website. I don't know clearly this.
5) If we type the text (font size-90pt) in #3x image, then it will automatically changes to 60pt in #1x image. right?
But in this link https://www.smashingmagazine.com/2015/05/retina-design-in-photoshop/#font-size , he wrote that
a text box with the font set to 16 pixels. But #2x this is 32 pixels,
and #3x it’s 48 pixels!
Not ideal, is it, having to constantly multiply by two or three? I
don’t know about you, but I could do without the constant math. When I
design, I want to know that 16 pixels is 16 pixels!
So, the text should be 16 px in any size of image 1x,2x or 3x or not?
6) These image sizes are for launch screen, isn't it? But, if I create an image for background of Login screen, then is it the same concept and save as these sizes of image ?
7) Above image size dimension is correct or not? But, in this https://developer.apple.com/ios/human-interface-guidelines/graphics/launch-screen/ website, the sizes are a little bit different.
Now, I'm trying to create a design for login background image. So, I was finding the sizes before I draw. But, after reading many articles of image sizes in Retina device, I've confused and got many questions in my mind.
That's why I write down my questions like this and I would like to say sorry that my question is long and make you feel not easy to understand.
Sorry again for my poor English.
I hope anyone would help me to answer all my questions in steps.Thanks for reading till the end. :)
You are asking way to much here. First off, you do not work in pixels. You work in points. These are 2 different units of measurements. On a 1x scale 1 point = 1x1 pixel, on a 2x scale 1 point = 2x2 pixel, and on a 3x scale, 1 point = 3x3 pixels.
Now when it comes to how to scale, people claim that you start big and you got small for best quality. This is simply not true. It all depends on the actual image as to how it will scale. So your goal is to find what works best for the image. I would recommend starting off from big to small, but if it doesn't work out as nice as you like, go small to big, then try a different scaling method.
I personally do not rely 100% on automation, I like to tweak all 3 sizes manually until the images are perfect, which makes sprite-kit really tough to work with in this department because I have to design my graphics in a way that counter act the hardware scaling. Bottom line is at the end of the day, do what is best for your app within your budget constraints.
Now when it comes to font sizes, again you are working in points, not pixels. Whoever told you that you need to multiply has no understanding of how retina display works. So when you do 16pt font, the system will automatically pick 32pt and 48pt. (But if you read it it will still say 16pt)
Try not to over think this matter, it is really simple to understand. The entire point of retina display is to provide a sharper image while maintaining the same experience, and it does this by offering more granularity in the way pixels are displayed. Each individual pixel is very very tiny, which makes it hard to see with your eyes. Instead they are companions to other pixels, so that when your eyes put the 2 pixels together, you get a better looking image that could not be produced by using a single colored pixel. When you work on your apps, you want to keep this in mind. This is why it stinks for new people to get into development. Everybody should start with the iphone 2g, then adapt their app to iphone 4. They will get a clear understanding of what retina is built for.
i have a little problem .. i am developing an SkinEngine that allow Delphi Vcl Application to be Skined . for this goal, i had developed a new file format (mSkin) in order to host my skin data .so my skin file contains 2 header , the first contains some information about the colors used by the skin , the second contains the bitmap used by skin (the bitmap type is Alpha channel bitmap in order to support transparency ).in my control i use a function to extract object bitmap from the bitmap(mSkin.Bitmap) and draw this bitmap onto my control . the problem is that when the bitmap is not shaped i got a bad quality when scaling the source bitmap .the size of the object bitmap is proportional to the control size (when the contol size changed ==> the bitmap siwe change too .)
i had try to read the vcl style to solve the problem .. but it seems to be very difficult to read .
is there a way to copy bitmap and Maintaining the quality ?
If you use bitmaps you simple can't do scaling without the problems you have. If you want scaling where e.g. a one-pixel border stays a one-pixel border, then you have to use a vector-based format for your images.
You need to divide that into 9 different bitmaps, like a 3x3 grid. then you only scale the middle on, the rest stay the same size but move. This link is for android but the same principles apply.
Here is another link. This is for flash, but it also explains the principle.
Try to use a resampling algorithm.
For upscaling, I like very much the B-Spline.
For simple content like yours, the hqnx family sometimes gives good results, and is very fast to render (even in real-time). For some pascal source code, you may take a look at this forum thread.
See also this more general question.
I'll first tell you the problem and then I'll tell you my solution.
Problem: I have a blank white PNG image approximately 900x900 pixels. I want to copy circles 30x30 pixels in size, which are essentially circles with a different colour. There are 8 different circles, and placed on the image depending on data values which I've created elsewhere.
Solution: I've used ImageMagicK, it's suppose to be good for general purpose image editing etc. I created a blank image
Image.outimage("900x900","white");
I upload all other small 30x30 pixel images with 'read' function.
I upload the data and extract vales.
I place the small 'circle' images on the blank one using the composite command.
outimage.composite("some file.png",pixelx,pixely,InCompositeOp);
This all works fine and the images come up the way I want them too.
However its painfully SLOW. It takes 20 seconds to do one image, and I have 1000 of them. Surely there must be a better way to do this. I've seen other researchers simulate images way more complex and way faster. It's quite possible I took the wrong approach. Maybe I sould be 'drawing' circles instead of 'pasting' them or something. I'm quite baffled. Any input is appreciated.
I suspect that you just need some library that is capable of drawing circles on bitmap and saving that bitmap as png.
For example my Graphin library: http://code.google.com/p/graphin/
Or some such. With Graphin you can also draw one PNG on surface of another as in your case.
You did not give any information about the platform you are using (only "C++"), so if you are looking for a platform independent solution, the CImg library might be worth a try.
http://cimg.sourceforge.net/
By the way, did you try drawing the circles using the ImageMagick C++ API Magick++ instead of "composing" them? I cannot believe that it is that slow.
Summary
Using Windows GDI to convert 24-bit color to indexed color, it seems GDI chooses colors which are "close enough" even though there are exact matches in the supplied palette.
Can anyone confirm this as a GDI issue or am I making a mistake somewhere?
Maybe there's a "please check the whole palette for color matches" flag which I've failed to find?
Note: This is not about quantizing. The source is 24-bit but contains 256 or fewer colors so an exact palette is trivial to calculate. The problem is GDI doesn't use the full palette.
Workaround
I've worked around the problem by mapping the colors myself but I'd prefer to use GDI as it should be better optimized. Problem is, it seems to be "fast but wrong."
Detailed description
My source image is 24-bit but uses 256 (or fewer) colors. I generate an exact palette for it and ask GDI to transfer the image into an indexed bitmap using that palette. For some pixels GDI chooses similar, but not exact, colors even though there are exact colors elsewhere in the palette. This ruins smooth gradients.
This problem happens with:
SetDIBitsToDevice
StretchDIBits
BitBlt
StretchBlt
The problem does not happen with:
SetPixel or SetPixelV in a loop (incredibly slow!)
Using my own code to do the mapping
I've tested this on:
Windows 7 (NVidia hardware/drivers)
Windows Vista (ATI hardware/drivers)
Windows 2000 (VMware hardware/drivers)
In every test I get the same results. (Not just the wrong colours but always the same wrong colors.)
I don't think the issue is color management (ICM/ICC profiles/etc.) as most of the APIs say they don't use it, I've tried explicitly turning it off on the GDI DC as well as via the V5 bitmap header, and I don't think it would apply within my vanlilla-Win2k VM.
Test Project
Code for a simple Win32/GDI/VS2008 test project can be found here:
http://www.pretentiousname.com/data/GdiIndexColor.zip
The Test1 function within Win32UI.cpp is the actual test. It has two arrays of RGBQUADs, one the source image and the other the exact palette for it. It verifies that the palette really is exact and then asks GDI to convert the image using the APIs mentioned above, testing the result each time. For each test it'll tell you the first incorrect pixel's before & after colors, or tell you that all pixels are correct if it worked.
Thanks!
Thanks for reading my question! Sorry if it's the result of me doing something really dumb! :-)
I ran into this exact same problem, eventually contacted Microsoft and provided them with a test case. In the test case I provided a gradient image that had 128 colors in a 24bit DIB, I then converted that to an 8bit DIB that was created with a color table containing all 128 colors from the 24bit image. After conversion, the 8 bit image had only used 65 of the 128 colors.
To sum up their response:
This is not a bug, GDI does use a close enough calculation when down converting the color depth of an image. This is not really documented anywhere, and the only way to insure all of the original colors will convert exactly is to manually manipulate the pixels yourself.
Are you using SetDIBColorTable()? This article seems to imply that, when drawing to a DIB, it is not sufficient to call SelectPalette() but that SetDIBColorTable() also needs to be called to set the palette for the DIB:
However, if the application is using
a DIB section, you create a logical
palette from the DIB colour table as
usual and then also pass the DIB
colour table to the DIB section with a
call to SetDIBColorTable(). Despite
what the "Platform SDK" documentation
of RealizePalette() appears to imply,
RealizePalette() does not adjust the
colour table of the DIB section.
The article contains some more information on drawing into palettized DIBs that may be relevant (see the section "Palettes and DIB sections").
I vaguely remember that you also need to call RealizePalette(hdc) after a palette is selected into a DC. We ditched our palette code so long ago that the code isn't even in our source tree anymore. I see from your code that you alrady tried this, but I suggest that you might want to play with that some more.
I do remember that the palette code was pretty fragile, and we stopped using it as soon as we could.
Some older AVI files would have 8 bit palettized video with a palette imbedded in the file, so playback code for those files would need to load an realize a palette. I remember that realize didn't do anything unless you were the foreground app, but that SHOULD only apply to screen DC's and not memory DC's.
If you searched around for sample source code that could play palettized AVI's you might find something that shows the magic formula for getting palettes to work.
Sorry I can't be more help.
I have an array of raw rgb data.
I would like to know how can I draw this pixels on the screen in Windows OS?
Now I use API function DrawDIBits, but I must turn up my image data.
I always use SetDiBitsToDevice, but drawDIBits could be okay as well (haven't checked).
As for the upside-down nature of the windows blit functions:
There is a workaround. If you pass a BITMAPINFOHEADER or BITMAPINFO structure to the function just negate the value in the bitmap-height member. This will tell GDI to do the blit as if the height would be positive, but interpret the data as beeing stored in a top-down order.
You may get a nice speed improvement by this "hack" as well.
If you want to shuffle the byte-order of the pixels (e.g. turn ARGB into BGRA or so) you can use the BITMAPV4HEADER structure and tell GDI how your pixel-data is organized. That's a functionality that is rarely used but works since WIN98. I'd say it's save to use it these days..
If you mean drawing it without reversing the (R,G,B) into (B,G,R), I don't know an automatic way to do that.
If you mean drawing it without padding each line to a multiple of 4 pixels, you can do it by drawing each line one at a time. It will be slow, though.